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SHZFBOASO  TOKEN  RING  LOCAL  AREA  NETWORKS  (LANS) : 
DATA  BIGHWAyS  TO  THE  FUTURE 


by 

Ross  L.  Bsnnstt 
Sparry  Marina  Inc. 
and 

Dr.  Alfrad  C.  Waavar 
Onivarslty  of  Virginia 
Dapartaant  of  computar  solanca 


1.  ABSTRACT 

The  design  of  naval  ships  is  beginning  to  be  impacted  by  the 
rapid  advances  in  high-speed  information  networks  being  placed  on 
them.  An  example  of  such  a  network  is  the  Navy's  emerging  SAFENET 
(Survivable  Adaptable  Fiber  Optic  Embedded  Network)  standard  [1]. 
These  networks  use  fiber  optics  media,  new  high-reliability 
networking  techniques,  and  developing  standards  in  hardware  and 
software. 

Sperry  Marine  has  pioneered  the  effort  to  place  high-speed 
data  networks  aboard  commercial  vessels  through  its  development  of 
SeaNET,  a  4  Hegabits/sec  (Mbps)  IEEE  802.5  [2]  standard  token  ring 
with  real-time  data  transfer  capability.  As  a  logical  advancement 
of  its  shipboard  networking  expertise,  Sperry  Marine  is  now 
developing  a  network,  with  associated  real-time  interfaces,  which 
will  meet  the  SAFENET  standard.  As  part  of  this  development 
effort,  the  University  of  Virginia  Computer  Networks  I,aboratory  has 
been  contracted  to  design  and  implement  a  software  version  of  the 
Xpress  Transfer  Protocol  (XTP)  [3],  the  light-weight  protocol 
specified  in  the  SAFENET  standard. 

This  paper  presents  a  summary  of  lessons  learned  through  the 
development  of  the  SeaNET  real-time  commercial  shipboard  network 
and  a  description  of  the  new  work  under  way  to  develop  a 
SAFENET-compatible  network.  Included  is  a  summary  analysis  of  the 
impact  such  a  network  will  have  on  future  ship  design. 
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ZNTRODaCTION 


Traditionally,  shipboard  equipment  has  been  distributed 
throughout  a  ship  in  the  form  of  stand-alone  systems  with  very 
little  interconnectivity  among  units.  This  approach  leads  to 
equipment  employing  a  variety  of  user  interfaces  which  require  more 
space  than  desired.  It  also  promotes  inefficiency  because  of  the 
myriad  different  controls  and  displays. 

Modern  techniques  allow  equipment  to  be  networked  together  to 
derive  the  maximum  benefit  from  the  fusion  of  data  from  many 
sources.  This  fused  data  can  now  be  accessed  through  integrated 
display  and  control  consoles.  When  fused  information  is  accessible 
at  user-friendly  centralized  locations,  higher  efficiency  is 
achieved.  Operational  decision-making  is  further  enhanced  by  the 
ability  to  monitor  data  with  microprocessor-based  units,  freeing 
the  operators  to  concentrate  on  the  decision-making  process. 

In  order  to  satisfy  the  requirements  for  integration  of 
shipboard  navigational  equipment,  Sperry  Marine,  in  conjunction 
with  the  University  of  Virginia  Computer  Networks  Laboratory,  has 
developed  an  Integrated  Bridge  System  (IBS)  that  uses  a  real-time 
token  ring  network  called  SeaNET.  The  network  Integrates  all  of 
a  ship's  bridge  equipment,  including  sensors,  navigation  units, 
display  devices,  radars,  and  steering  control  units. 

The  design  and  development  of  SeaNET  has  resulted  in  four 
major  attributes: 

•  The  hardware  and  software  is  based  on  existing  standards. 

•  It  is  able  to  interface  all  types  of  equipment,  whether 
made  by  Sperry  Marine  or  by  other  manufacturers. 

•  It  has  distributed  control  so  that  single  point  failures 
will  not  bring  down  the  network. 

•  It  is  flexible,  expandable,  and  able  to  be  integrated 
with  other  shipboard  data  systems. 

The  first  requirement  insures  us  that  second  sourcing  of  components 
is  available  and  that  the  network  will  be  acceptable  to  a  wider 
field  of  customers.  The  second  requirement  enables  customers  to 
configure  their  own  system  with  navigational  units  with  which  they 
are  most  comfortable.  The  third  requirement  addresses  the 
reliability  issue.  Real-time  systems  must  continue  to  operate  even 
if  one  of  the  stations  on  the  network  falls.  Finally,  the  fourth 
requirement  Insures  that  the  Sperry  IBS  can  share  information  with 
other,  non-SeaNET-based  systems  such  as  an  engine  room  monitoring 
system  and  SAFENET. 
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IAN  SBMtCH  AND  SELECTION 


In  1986,  Sperry  Marine  contracted  with  the  Computer  Networks 
Laborato^  at  the  University  of  Virginia  to  evaluate  the 
suitability  of  extant  LAN  products  (Ethernet,  token  bus,  token 
ring,  etc.)  and  to  recommend  one  for  shipboard  use.  The  result  of 
this  analysis  was  the  selection  of  the  token  ring  topology.  The 
primary  advantages  are: 

(1)  Token  rings  easily  accommodate  copper  or  fiber  media,  or  both, 
on  the  same  network;  for  a  ship,  this  means  we  can  run 
inexpensive  shielded  twisted  pair  media  in  low-noise  areas 
such  as  the  bridge,  and  reserve  the  higher-cost  fiber  optic 
media  for  high-noise  areas  such  as  the  engine  room. 

(2)  Commercially  available  token  rings  provide  a  range  of 
performance  options,  from  4  to  100  Mbps. 

(3)  They  can  be  made  fault-tolerant  by  using  a  star-ring  topology 
(i.e,,  wiring  centers)  and  counter-rotating  dual  ring  design. 

(4)  Choosing  the  IEEE  802.5  token  ring  (at  4  or  16  Mbps)  assures 
us  of  multiple  hardware  vendors  and  conformance  to 
International  standards. 

(5)  The  token  ring  topology  and  the  IEEE  802,5  standard  are 
consistent  with  the  Navy's  direction  for  SAFENET. 

4.  SEANET  DESIGN  AND  DEVELOPMENT 

Once  the  selection  of  the  IEEE  802.5  standard  was  established, 
Sperry  contracted  the  University  of  Virginia  Computer  Networks 
Laboratory  to  develop  a  real-time  network  interface  which  could 
handle  the  sensor  update  rate  requirements.  At  the  same  time, 
Sperry  performed  an  investigation  to  select  the  network  components 
and  a  ruggedized  PC-based  unit  to  be  used  for  the  network  interface 
unit  (_NIU) .  Sperry  also  developed  several  interfaces  for  sensors 
to  be  attached  to  the  network,  including  the  selection  of  the 
analog  and  digital  interface  boards  required  for  each  sensor. 
Finally,  Sperry  developed  three  sophisticated  units  for  the  fusion, 
control  and  display  of  navigation  and  ship  control  information. 

Real-time,  Network  Interface 

The  Computer  Networks  Laboratory  )cnew  from  their  previous 
network  performance  evaluations  that  the  commercially  available  ISO 
protocol  packages  (1)  would  not  meet  our  real-time  performance 
requirements  and  (2)  were  really  overkill  for  a  relatively  short, 
single  segment  LAN  with  a  modest  number  of  stations.  To  solve  this 


problem,  they  designed  and  implemented  a  real-time  network 
interface,  provided  as  a  set  of  library  functions  which  the  user 
links  into  his  application  program.  To  encourage  interoperability, 
the  interface  adheres  strictly  to  the  IEEE  802.2  logical  link 
control  (LLC)  standard  [4]. 

SeaNET  provides  a  basic  datagram  service,  with  optional 
acknowledgements  and  checksums,  to  multiple  application  processes 
running  on  microcomputers.  Communication  occurs  through  sockets 
which  are  equivalent  to  IEEE  802.2  LSAPs  (link  service  access 
points) .  The  user  interface  is  a  set  of  'C  procedure  calls  which 
create  and  manage  sockets,  set  options,  send  and  receive  messages, 
and  report  network  status  [5]. 

Messages  received  from  the  network  are  filtered  at  both  the 
hardware  level  and  software  level .  At  the  hardware  level ,  each 
station  assigns  itself  to  a  functional  group  which  becomes  part  of 
the  address  for  the  network  interface  board.  When  a  message  is 
received  whose  destination  address  matches  the  functional  address 
of  a  station,  the  message  is  copied  to  the  incoming  message  buffer. 
The  real-time  software  interface  then  looks  at  the  header  informa¬ 
tion  of  the  message  itself  to  determine  if  the  message  is  meant  for 
any  of  the  tasks  requesting  services.  If  not,  the  message  is 
ignored.  Otherwise,  the  task  is  notified  of  receipt  of  a  message 
and,  when  requested  to  do  so,  the  network  interface  copies  the 
message  into  the  task's  buffer. 

AjlI  Hardware  Selection  and  Configuration 

There  are  four 
basic  components  of  most 
token  ring  networks  (see 
Figure  1) : 

•  processor  units 
(nodes)  containing 
the  applications 
which  use  the  net¬ 
work  as  a  data 
transfer  vehicle 

•  network  interface 
boards  which  plug 
into  the  processor 
units  and  control 
the  actual  transfer 
of  data  on  and  off 
the  network 
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•  network  wiring  centers  (NWCs)  which  contain  bypass  switches 

allowing  stations  to  be  attached  and  disconnected  from  the 

network  without  halting  the  network 

•  the  network  cable 

_ Initial  Prototype.  The  initial  SeaNET  prototype 

development  was  started  more  than  four  years  ago.  At  that  time, 
ProNET-lo'  network  components  were  used.  This  was  necessary 
because,  although  the  token  ring  standard  was  already  adopted  by 
the  IEEE  802.5  committee,  the  hardware  was  not  yet  commercially 
available.  The  ProNET-lo  hardware  is  similar  to  the  IEEE  standard 
and  allowed  easy  transition  to  the  802.5  standard  as  our 
development  effort  progressed. 

PC-based  units  were  selected  to  serve  as  network  interface 
units  (NIUs)  because  they  offered  both  lower  development  cost  and 
lower  cost  for  our  customers.  Because  of  the  harsh  shipboard 
environment,  we  investigated  several  potential  units  as  NIU 
candidates.  Our  investigation  resulted  in  selection  of  a  PC 
chassis  with  a  passive  backplane,  allowing  us  to  configure  our 
units  with  various  manufacturers'  microprocessor  boards,  sensor 
interface  boards,  and  network  interface  boards. 

The  prototype  was 
configured  as  shown  in 
Figure  2 .  We  selected 
the  Sperry  MK-37E  gyro¬ 
compass  as  the  Initial 
sensor  since  it  has  the 
highest  update  rate  re¬ 
quirement.  The  gyro  NIU 
was  initialized  with  the 
current  heading.  This 
was  done  remotely  using 
a  PC  workstation 
attached  to  the  network. 

Once  initialized,  the 
NIU  began  receiving  step 
(1/6')  changes  from  the 
gyrocom.'>ass  and  used 
these  changes  to 
calculate  a  new  absolute  heading  for  transmission  on  the  network. 
When  this  data  was  received  by  the  autopilot  NIU,  it  was  converted 
back  to  step  changes.  These  changes  were  fed  to  the  Sperry  SRP- 
690  autopilot  causing  its  heading  indicator  to  turn. 


Figure  2  -  Prototype  Configuration 


proNET-lo  is  a  trademark  of  Proteon,  Inc. ,  Westborough,  MA. 
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Once  we  proved  these  interfaces  worked  across  our  SeaNET 
prototype,  we  began  developing  a  suite  of  additional  sensor 
interfaces  for  other  Sperry  equipment.  This  was  done  in  a  phased 
manner  with  each  interface  being  tested  and  checked  for  performance 
before  implementing  the  next. 

b.  Conversion  of  Prototype  to  Target  System.  When  the  IEEE 
802.5  4-Mbps  token  ring  products  became  available,  all  interfaces 
were  converted  to  this  standard.  The  real-time  network  interface 
was  ported  to  both  the  Proteon  ProNET-4^  token  ring  interface  board 
and  the  IBM  PC^  Token  Ring  Adapter.  Since  the  IBM  board  showed 
better  performance  in  raw  throughput  measurements,  we  selected  this 
board  as  the  primary  network  interface  for  our  NIUs,  with  the 
Proteon  board  to  be  used  for  second  sourcing. 

Recently  we  acquired  several  of  the  new  IBM  16/4  PC  Token  Ring 
Interface  Boards.  These  boards  are  switchable  between  4  and  16 
Mbps.  We  were  pleased  to  find  that  these  boards  are  completely 
compatible  with  our  applications  and  require  no  changes  to  our 
real-time  interface. 

The  primary  reason  for  SeaNET 's  ease  of  portability  is  its 
modular  design.  Operations  which  are  network  dependent  (e.g.,  the 
device  driver  for  a  particular  vendor's  token  ring  interface)  are 
isolated  from  the  user  interface.  From  the  point  of  view  of  the 
user,  the  interface  to  SeaNET  is  identical  regardless  of  the  token 
ring's  speed  or  its  manufacturer. 

c.  Performance.  SeaNET 's  most  important  attributes  are  its 
high  throughput  and  low  latency  performance  characteristics. 
Figures  3-5  show  SeaNET 's  performance  when  executing  on  a  25  MHz 
Intel  80386  CPU.  These  figures  compare  SeaNET  performance  for  two 
token  ring  interfaces:  the  4-Mbps  ProNET-4  and  the  10-Mbps  ProNET- 
10. 


Figure  3  records  the  load  generated  by  a  single  station  for 
messages  of  various  lengths.  The  graph  compares  the  performance 
of  the  ProNET-4  using  programmed  I/O  (solid  line) ,  ProNET-10  using 
direct  memory  access  (dashed  line) ,  and  the  ProNET-10  using 
programmed  I/O  (dotted  line).  Using  ProNET-4,  SeaNET  can  sustain 
an  offered  load  of  about  2  Mbps.  That  is  one  half  the  network's 
total  capacity  generated  by  a  single  station!  Using  ProNET-10, 
throughput  rises  to  almost  4  Mbps. 


^  proNET-4  is  a  trademark  of  Proteon,  Inc.,  Westborough,  MA. 

^  IBM  and  PC  are  trademarks  of  International  Business  Machines 
Corporation. 
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Transmillsr  Lead  (Kbits/sec) 


Figure  3  -  Transmitter  Load  (Kbits/sec) 


For  a  control  system,  total  station  throughput  may  be  less 
important  than  the  message  rate,  i.e.,  how  fast  individual  control 
messages  can  be  emitted.  Figure  4  shows  the  transmitted  load  in 
units  of  packets/sec.  For  short  (100-byte)  messages  which  are 
typical  of  control  applications,  SeaNFT  can  sustain  636  packets/sec 
on  ProNET-4  and  2380  pac)cets/sec  on  ProNET-10. 


Figure  4  -  Transmitter  Iioad  (packets/sec) 


In  any  real-time  system,  end-to-end  latency  is  a  very 
important  factor.  Our  measurements  of  end-to-end  delay  include  all 
factors  which  a  user  message  would  see:  posting  the  message 
buffer,  interacting  with  the  operating  system,  copying  the  message 
across  the  backplane  bus,  network  access  time,  and  network 
transmission  and  propagation  delays.  Figure  5  shows  elapsed  time 
from  when  a  user  posts  a  message  for  transmission  until  the  message 
is  received  by  the  destination's  application  program.  SeaNET 
delivers  100-byte  messages  end-to-end  in  2.63  milliseconds  for  the 
ProNET-4  and  in  680  microseconds  for  the  ProNET-10. 


Figure  5  -  End-to-end  Delay  (milliseconds) 


is _ Network  Wiring  Centers.  All  stations  on  the  SeaNET  token 

ring  attach  to  the  network  through  network  wiring  centers  (NWCs)*. 
These  units  have  normally-closed  relays  in  each  station  attachment 
port  which  are  caused  to  open  via  an  electrical  signal  from  the 
attachment  station  itself.  Removal  of  this  electrical  signal 
causes  the  relay  to  return  to  its  closed  position,  thus  bypassing 
the  station. 
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Some  manufacturers  refer  to  these  units  as  multistation 
access  units  (MAUs) .  This  paper  refers  to  all  such  units  as 
network  wiring  centers  (NWCs) . 
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Two  basic  types  of  NWCs  exist:  unpowered  and  powered.  Each 
of  these  units  usually  contains  8  ports  for  station  attachment  and 
two  additional  ports  for  connection  to  other  NWCs.  The  unpowered 
units  contain  no  indicators  to  inform  users  of  their  health  or 
which  stations  are  currently  active  on  the  ring. 

Powered  NWCs  usually  have  LEDs  to  indicate  that  the  unit  is 
powered  up  and  to  indicate  which  stations  are  active.  A  subclass 
of  the  powered  NWCs  are  the  "intelligent"  NWCs  which  allow  special 
diagnostic  tools  and  network  configuration  management  programs  to 
have  access  to  the  network.  Another  subclass  are  the  "repeating" 
NWCs  which  are  used  to  boost  the  network  signal  over  long  runs. 
A  third  class  of  powered  NWCs  are  the  fiber  optic  units  which  allow 
fiber  optic  cabling  to  be  used  between  NWCs.  Some  units  have  all 
of  these  capabilities. 

Sperry  initially  chose  the  IBM  passive,  unpowered  NWCs  for 
their  installations  because  of  their  low  cost  and  simplicity. 
However,  it  has  been  discovered  that  severe  vibration  or  strong 
magnetic  fields  can  cause  the  internal  relays  to  switch  to  an 
improper  state.  This,  in  turn,  can  cause  degradation  or,  in  some 
cases,  complete  failure  of  the  network.  Of  course,  a  shipboard 
environment  can  have  both  severe  vibrations  and  strong  magnetic 
fields  present.  Therefore,  we  have  now  switched  to  the  Proteon 
powered  NWCs  which  insure  that  the  relays  are  held  in  their  proper 
state. 


e.  Network  Monitor.  During  the  development  of  the  SeaNET 
real-time  interface,  the  University  of  Virginia  Computer  Networks 
Laboratory  also  developed  a  real-time  network  monitor.  This 
monitor  contains  both  a  graphics  mode  and  a  trace  mode. 

In  graphics  mode,  the  monitor  displays  color-coded  scroll 
graphs  of  recent  network  traffic.  Network  data  is  sampled  at  a 
user-defined  rate  (up  to  100  times  per  second)  and  a  graph  shows 
traffic  intensity  in  packets/ sec  and  bits/sec. 

Trace  mode  allows  the  user  to  trap  all  network  traffic,  or 
any  subset  as  specified  by  a  user-defined  address  filter.  Trace 
data  may  be  displayed  on  the  screen  in  real-time  (i.e.,  as  it  is 
captured)  or  diverted  to  a  disk  file  for  off-line  analysis. 

The  user  can  also  define  event  or  frequency  alarms.  Whenever 
these  events  occur,  the  monitor  notifies  the  user  and  then  displays 
the  sequence  of  messages  which  preceded  and  followed  the  alarm 
event . 
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NMEA  0183  Software  Protocol  for  Real-Time  Data 

The  NMEA  0183  Standard  for  Interfacing  Marine  Navigational 
Devices  [6]  is  gaining  worldwide  acceptance  as  a  standard  in  the 
marine  Industry.  This  is  an  8-bit  ASCII  protocol  which  allows  a 
"talker"  to  transfer  data  to  one  or  more  "listeners"  in  a  prescrib¬ 
ed  sentence  format.  The  0183  Standard  contains  a  list  of  sentences 
which  has  been  approved  by  the  NMEA  0183  Committee.  Two  example 
sentences,  one  for  heading  data  and  one  for  position  data,  are 
shown  below: 


$HEHDT,032,T*30<CR><LF> 


where : 


$  =  start  of  sentence  indicator  (Hex  24) 

HE  =  talker  identifier  (Gyro,  Earth  Seeking) 

BDT  =  sentence  identifier  (heading,  degrees,  true) 
032  =  heading  in  degrees 

T  =  true 

*  =  checksum  delimiter 

30  =  checksum 

<CR><LE>  =  sentence  terminator  (Hex  ODOA) 


$I.C0LL,  4728 . 31,M,  12254 .25,  W*6D<CR><Lr> 

where:  $  =  start  of  sentence  indicator  (Hex  24) 

LC  *  talker  identifier  (Loran  C) 

GLL  =  sentence  identifier  (geographic  latitude  & 
longitude) 

4728. 31, H  =  Lat.  47"  28.31"  North 

12254. 25, W  =  Lon.  122"  54.25"  West 

•  =  checksum  delimiter 

6D  -  checksum 

•cCRxIlPy  =  sentence  terminator  (Hex  ODOA) 

The  checksum  field  is  optional.  It  is  calculated  by  exclusive 
or'ing  all  characters  between,  but  not  including,  the  "$"  and  the 
and  converting  the  two  nibbles  (4  bits  each)  of  the  resulting 
hexadecimal  value  to  two  ASCII  characters  (8  bits  each) .  All 
SeaNET  NMEA  0183  messages  Include  the  checksum. 

Sperry  selected  the  NMEA  0183  protocol  to  transfer  its  real¬ 
time  data  over  SeaNET  because  it  is  the  only  recognized  standard 
in  the  marine  industry  today.  Any  devices  attached  to  the  network 
which  support  this  protocol  can  communicate  with  each  other  over 
the  network. 

The  sensor  messages  are  sent  onto  the  network  in  a  "broadcast" 
mode.  No  acknowledgements  are  used.  If  a  message  becomes 
corrupted  during  transfer,  the  message  is  simply  discarded  and  the 
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"listener"  waits  for  the  next  uncorrupted  message  to  be  received. 
It  is  expected  that  a  "listener"  will  Implement  a  timeout  mechanism 
in  case  a  valid  message  is  not  received  within  a  required  period 
of  time. 

File  Transfer 

SeaNET  also  provides  the  capeUbllity  to  transfer  files  across 
the  network.  So  as  not  to  interfere  with  the  real-time  sensor 
data,  the  file  transfer  facility  breaks  files  up  into  small  packets 
of  less  than  2000  bytes.  Virtual  circuits  are  first  established 
between  units.  The  packets  are  then  sent  in  a  sequential  manner 
with  validity  checks.  Error  detection  and  reporting  Insures  that 
the  operator  is  informed  if  the  file  transfer  failed  for  any 
reason. 

Real-Time  Multi-Tasking  Executive  tMTX) 

Since  Sperry  Marine's  SeaNET  is  primarily  concerned  with  the 
gathering  and  transfer  of  real-time  data,  Sperry  Marine  has  also 
developed  its  own  real-time  multi-tasking  executive.  This 
executive,  called  MTX,  provides  the  following  services: 

•  convenient  access  to  device  Interfaces 

•  configuration  of  multiple  sensor  interfaces  into  one  NIU 

•  scheduling  of  multiple  tasks 

•  timing  services 

•  efficient  intertask  communications 

MTX  simplifies  a  system's  program  by  moving  the  timing  and 
scheduling  details  into  the  realm  of  the  runtime  system  and  out  of 
the  program  Itself.  By  simplifying  the  program  it  becomes  easier 
to  design  and  understand,  thus  improving  software  development 
efficiency. 

One  traditional  programming  method  is  the  top-down,  functional 
decomposition  approach.  In  this  method,  each  level  of  refinement 
is  designed  to  satisfy  precisely  the  requirement  of  the  level 
above.  It  makes  sense.  But  when  the  top  level  requirements  change 
(as  they  always  do)  the  entire  structure  is  affected. 

MTX,  on  the  other  hand,  adheres  to  the  object-oriented 
programming  concepts.  In  this  method,  each  object  module  comprises 
some  data  and  the  functions  which  access  and  manipulate  it.  The 
only  way  the  data  may  be  accessed  is  through  its  defined  functions. 
The  functions  as.:ociated  with  each  object  may  be  invoked  by  any  of 
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the  various  tasks  in  the  system  and  possibly  concurrently.  By 
structuring  the  system  in  this  manner,  the  scope  of  conflicts 
between  tasks  over  a  particular  data  item  is  limited  to  the  module 
which  encapsulates  it. 

Another  advantage  of  this  approach  is  the  generation  of 
reusable  modules.  This  is  because  the  module  can  be  treated  as  an 
entity  in  itself  without  having  to  care  about  its  relation  to  the 
particular  system  being  built.  This  has  other  implications  as  the 
system  requirements  are  modified  over  its  lifecycle.  The  in¬ 
dividual  modules  are  less  likely  to  change  since  their  design  is 
not  strongly  tied  to  the  particular  system  requirements.  This 
advantage  also  simplifies  software  configuration  control. 

4.6  Equipment  Interfaces 

Sperry  Marine  has  developed  an  extensive  suite  of  equipment 
interfaces  to  SeaNET.  Following  is  a  partial  list  of  these 
interfaces.  The  Interface  type  is  shown  in  parentheses.  Those 
that  are  shown  as  "direct  connect"  connect  directly  to  the  network. 
All  others  interface  through  an  MIU. 

•  Gyrocompass  (IX,  90X,  I80X,  360X,  combined  1X/36X,  step) 

•  Rudder  Angle  Indicator  (synchro) 

•  Sperry  SRD-421  Dual  Axis  Doppler  Speed  Log  (RS-422) 

•  40  Knots/Revolution  Speed  Ijog  (synchro) 

•  Sperry  501  TR/GPS  Satellite  Navigator  (RS-232) 

•  Sperry  ADG-6000  Gyropilot  (RS-422) 

•  Sperry  RASCAR  Raster  Scan  Collision  Avoidance  Radar  (RS- 
232) 

•  Northstar  800  Loran-C  (RS-422) 

•  Robertson-Shipmate  RS4000  Oecca  Navigator  (RS-422) 

•  Honeywell  ELAC  Echo  Sounder  (parallel  BCD) 

•  Coastal  Climate  Weatherpak  Weather  Station  (RS-422) 

•  Sperry  MCS2B  Satellite  Communicator  (modem/PABX) 

•  Sperry  Navigation  Workstation  (direct  connect) 

•  Sperry  Voyage  Management  Station  (direct  connect) 

•  Sperry  Position  Filter  Module  (direct  connect) 

•  Sperry  Socket  Scanner  (direct  connect) 

•  UVA  Network  Performance  Monitor  (direct  connect) 

•  ESA  Engine  Room  Monitoring  System  (RS-422) 

New  interfaces  are  being  added  continuously  as  each  new  system  is 
designed  to  meet  the  customer's  exact  requirements. 

Sj — Navigation  Workstation  and  Vovaoe  Management  Station.  The 
Sperry  Navigation  Workstation  (NWS)  and  Voyage  Management  Station 
(VMS)  are  closely  related  products  which  provide  centralized  ship 
control  and  real-time  systems  monitoring.  The  NWS  allows  develop¬ 
ment  of  voyage  plans  and  digitized  charts  which  can  be  transferred 
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to  the  VMS  via  the  network,  and  can  serve  as  a  backup  unit  for  the 
VMS.  The  VMS  provides  display  and  tracking  against  the  voyage 
plans  and  digitized  charts.  It  also  allows  display  of  sensor  data, 
data  logging,  and  track  plotting.  The  VMS  has  a  state-of-the-art 
touch  screen  display  which  provides  the  operator  with  the  most 
natural  and  direct  user  interface.  New  displays  can  readily  be 
added  as  more  sensor  interfaces  become  available  and  new  applica¬ 
tions  are  implemented. 

_ Raster  Scan  Collision  Avoidance  Radar  fRASCAR^ .  The 

Sperry  Raster  Scan  Collision  Avoidance  Radar  (RASCAR)  also  has 
close  interaction  with  the  VMS.  Navlines  and  target  files  can  be 
transferred  between  these  units  via  SeaNET.  Position  and  sensor 
information  is  also  exchanged  between  these  units  at  regular 
intervals.  Like  the  VMS,  the  RASCAR  has  a  state-of-the-art  touch 
screen  user  interface. 

_ Position  Filter  Module  fPFMi .  The  Sperry  Position  Filter 

Module  (PFM)  receives  position,  speed,  heading,  set,  drift,  and 
other  related  data  from  the  network.  The  operator  can  input  the 
required  offsets  for  each  position  sensor  remotely  via  the  VMS  or 
NWS.  The  PFM  employs  a  Kalman  filter  which  uses  this  information 
to  calculate  the  best  estimate  of  true  position,  speed,  and 
heading.  The  result  is  then  sent  onto  the  network  for  use  by  other 
navigational  units. 

is _ Satellite  Communicator  fSATCOMi .  The  Sperry  Satellite 

Communicator  (SATCOM)  is  interfaced  to  the  network  via  the  SATCOM 
NIU.  This  allows  the  transfer  of  information  and  reports  between 
ship  and  shore.  Using  Sperry  Marine's  STARBAUD  software,  the 
SATCOM  sends  data  48  times  faster  (2400  baud  versus  50  baud)  than 
a  conventional  SATCOM  with  telex.  The  normal  effective  data 
transmission  rate  is  about  1700  baud,  allowing  for  protocol  and 
error  correction.  However,  text  compression  raises  the  effective 
rates  to  3600  baud  or  higher. 

Lil  Configuration  Management 

Configuration  management  is  an  important  element  of  Sperry 
Marine's  success  in  the  IBS  marketplace.  A  database  of  hardware 
components  with  their  corresponding  part  numbers  and  prices  is 
available  for  generating  proposals  and  satisfying  purchase  orders. 
A  database  of  software  interfaces  for  SeaNET-supported  equipment 
makes  configuration  of  the  NIUs  flexible  and  efficient. 

System  block  diagrams  can  be  generated  and  revised  very 
quickly  using  our  in-house  graphics  workstations  and  dateUsase 
libraries.  This  capability  allows  us  to  show  a  customer  a 
conceptional  drawing  of  his  system  before  it  is  actually  imple¬ 
mented.  During  negotiations,  requested  modifications  and  suggested 
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alternatives  which  address  specific  customer’s  needs  can  be  easily 
included.  These  drawings  can  then  be  given  directly  to  the 
configuration  team  for  system  build  and  checkout. 

All  software  is  stored  and  issued  under  control  of  Sperry's 
Engineering  Computer  Operations  (ECO) .  The  ECO  operates  under 
strict  control  procedures  for  software  updates  and  maintenance. 
The  ECO  maintains  all  Information  and  software  support  tools 
necessary  to  re-create  current  and  past  versions  of  each  software 
element. 

SyetCT  Testing 

Sperry  Marine  has  implemented  an  IBS  System  Validation  program 
specifically  aimed  at  addressing  the  special  issues  involved  with 
testing  such  highly  interactive  systems.  This  program  begins  with 
the  IBS  Validation  Policy  and  IBS  Validation  Methodology  documents 
which  address  these  issues  in  general  terms.  There  is  also  a  set 
of  Test  Procedures  which  addresses  the  common  components  of  all 
Sperry  IBS  systems.  Finally,  a  separate  set  of  Test  Procedures  is 
produced  for  each  Individual  system  which  addresses  the  specific 
differences  in  software  and  hardware  components  peculiar  to  the 
actual  system  under  test.  The  Test  Procedures  are  generated  using 
the  Functional  Specification,  the  Operator's  Manual,  and  other 
pertinent  system  documentation. 

Several  simulators  have  been  developed  which  allow  data  from 
actual  voyages  to  be  replayed  for  test  purposes.  Adverse 
conditions,  such  as  loss  of  sensor  data  and  erratic  sensor 
readings,  can  also  be  simulated  to  test  their  effects  on  the 
system. 

installatign? 

The  SeaNET-based  Sperry  Marine  IBS  is  installed  or  is  being 
installed  on  more  than  two  dozen  vessels  throughout  the  world.  A 
partial  list  of  these  installations  is  shown  below: 

•  North  Sea  Project  -  MS  XjANCE 

•  Finmare  (Italy)  -  4  Ferries,  6  Container  Ships 

•  P  &  0  Cruises  (Italy)  -  2  Cruise  Ships 

•  RCCL  (France)  -  3  Cruise  Ships 

•  I,auritzen  (Denmark)  -  3  Reefers 

•  Bell  Lines  (Japan)  -  l  container  Ship 

•  Exxon  (USA)  -  1  Tanker 

•  MODO  (Korea)  -  1  Roll-on/Roll-off  Vessel 

•  B.A.S.  (U.K. )  -  1  Research  Vessel 

•  U.S.  Navy  -  CVN-72  (U.S.S.  Abraham  Lincoln) 
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Installation  of  a  system  aboard  the  U.S.S.  Abraham  Lincoln 
(CVN-72)  demonstrates  the  use  of  commercial  grade  equipment  on 
military  combatants.  rigure  6  shows  the  configuration  of  this 


system.  The  sensors  are  interfaced  through  three  NIUs,  one  80286- 
based  unit  and  two  8088-based  units.  In  addition  there  is  a  remote 
video  RASCAR  slave  monitor  installed  in  the  Captain's  Cabin.  Two 
scan  converters  are  Installed  which  allow  the  RASCAR  and  VMS 
displays  to  be  sent  onto  two  of  the  ship's  TV  channels  for 
distribution  to  other  areas  of  the  ship. 

There  are  two  network  wiring  centers  located  approximately  450 
feet  apart.  These  units  are  connected  using  type  SU-7  (7  shielded, 
twisted  pair)  cabling.  When  no  stations  are  active  on  one  end, 
such  as  when  the  VMS  in  the  Strike  OPS  area  is  turned  off,  the 
total  cable  length  between  these  two  units  becomes  quite  long 
(i.e.,  about  900  feet).  Although  no  problems  have  been  en¬ 
countered  due  to  this  distance,  the  installation  of  fiber  optic 
components  would  insure  that  noise  problems  would  not  be  a  factor 
over  such  a  distance.  The  replacement  of  the  network  wiring 
centers  with  fiber  optic  wiring  centers  and  replacement  of  the  SU- 
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7  cable  with  multi-mode  fiber  optic  cable  is  all  that  is  required 
to  accomplish  this. 

4.10  Lessons  Learned 

Through  the  design,  implementation  and  refinement  of  SeaNET, 
several  lessons  have  been  learned.  First,  we  have  found  that  there 
are  not  only  advantages  but  also  disadvantages  in  the  use  of 
standards.  For  example,  the  HHEA  0183  protocol  standard  makes  it 
difficult  to  place  sensor  information  on  the  network  for  which  no 
"approved"  sentences  exist.  By  the  time  the  NMEA  0183  Committee 
reviews  requested  additions  or  changes,  many  are  already  imple¬ 
mented  and  in  the  field.  One  can  only  hope  at  that  point  that  they 
will  be  approved.  If  not,  a  decision  must  be  made  to  either  change 
the  design  or  leave  it  as  it  is,  knowing  that  deviations  from  the 
standard  are  now  present  and  will  remain  as  such. 

Another  lesson  was  learned  from  the  message  addressing  schemes 
used.  Initially,  only  the  software  level  "sockets"  were  used  for 
filtering  messages.  Since  sensor  data  was  broadcast  to  all  nodes, 
this  resulted  in  sensor  interface  NIUs  receiving  their  own 
messages,  effectively  doubling  the  processing  of  these  messages 
for  each  unit.  When  heading  updates  are  occurring  at  eight  times 
a  second,  this  additional  processing  affects  performance 
dramatically.  Therefore,  we  implemented  hardware  level  functional 
addressing  which  is  supported  by  the  IEEE  802.5  interface.  This 
places  more  burden  on  the  hardware  interface  itself  and  allows  the 
main  processor  to  concentrate  on  other  work,  thus  improving 
performance. 

We  also  proved  the  value  of  thorough  system  testing.  It  is 
not  sufficient  to  simply  perform  exhaustive  unit  testing  of  each 
device  to  be  integrated.  Testing  of  interactions  with  other 
devices  often  reveals  problems  which  are  not  caught  during  unit 
testing.  Furthermore,  total  confidence  can  never  be  placed  in  the 
use  of  simulators  alone  for  system  testing.  When  dealing  with 
products  from  other  customers,  we  have  often  found  simulators  to 
be  inadequate.  Discrepancies  between  documentation  and  reality 
occur  frequently.  There  is  no  substitute  for  bringing  the  actual 
equipment  in-house  for  final  checkout. 

S.  8AFEHET  DEVELOPHEMT  EFFORT 

The  SAFENET  committee  was  organized  by  the  Naval  Ocean  Systems 
Center  (NOSC)  in  early  1986.  It  consists  of  industry  and  govern¬ 
ment  volunteers  tasked  with  developing  a  set  of  tactical  communica¬ 
tions  standards  for  the  Navy.  The  committee  meets  bi-monthly  to 
discuss  progress  of  its  sub-committees  and  to  give  opportunity  for 
Industry  and  government  participants  to  present  information  about 
their  products  and  applications.  As  a  result  of  this  effort. 


3.17 


several  standards  are  evolving.  The  first  are  the  SAFENET  I  and 
SAFENET  II  standards  themselves.  These  two  standards  define  the 
hardware,  software,  and  network  management  requirements  for  use  by 
local  area  networks  in  Naval  applications. 

The  SAFENET  I  standard  applies  to  those  applications  which 
utilize  the  IEEE  802.5  Token  Ring  standard.  It  includes  both  the 
original  4-Hbps  data  rate  and  the  new  16-Mbps  data  rate.  The 
SAFENET  II  standard  applies  to  those  applications  which  utilize  the 
100-Mbps  ANSI  X3T9.5  Fiber  Distributed  Data  Interface  (FDDI) 
standard  [7].  Aside  from  the  difference  in  data  rates  and 
associated  hardware,  the  two  standards  are  virtually  identical  in 
their  basic  specifications,  each  specifying  dual,  counter-rotating 
rings  and  fiber  optic  media  throughout. 

Sperry  Marine  has  followed  the  development  of  the  Navy's 
SAFENET  standard  with  much  interest.  Our  SeaNET  development 
history  closely  parallels  that  of  SAFENET.  Our  selection  of  the 
IEEE  802 . 5  token  ring  standard  was  occurring  at  the  same  time  that 
the  SAFENET  committee  was  making  the  same  decision. 

Since  SeaNET  was  initially  targeted  for  the  cost-competitive 
commercial  shipping  industry,  the  added  cost  of  redundant  rings  was 
not  practical.  Where  necessary,  critical  operational  functions  are 
backed  up  with  direct  links  between  units.  An  example  of  this  is 
the  direct  connection  of  the  gyrocompass  to  the  autopilot.  The 
primary  link,  SeaNET,  provides  the  autopilot  with  heading  from 
various  sources,  including  the  PFM.  If  the  network  fails,  the 
backup  link  allows  the  autopilot  to  continue  to  operate  properly. 

Sperry  also  realized  that  most  customers  would  not  want  to  pay 
the  additional  cost  of 
installing  a  fiber  optic 
network.  For  this  reas¬ 
on,  all  SeaNET  installa¬ 
tions  to  date  have  used 
shielded  twisted  pair 
cabling.  However,  as 
noted  earlier,  fiber 
optic  cabling  is  avail¬ 
able  between  wiring  cen¬ 
ters  if  requested. 

SAFENET  specifies 
its  own  real-time  light¬ 
weight  message  passing 
protocol  called  Xpress 
Transfer  Protocol  (XTP) . 

The  SeaNET  real-time 
protocol  satisfies  only 


Figure  7  -  Protocol  Stack  Comparison 


the  bottom  two  layers  of  the  ISO  protocol  stack  [8].  When  XTP  is 
placed  above  a  real-time  protocol  such  as  SeaNET,  the  bottom  four 
layers  of  the  ISO  protocol  stack  are  satisfied  while  maintaining 
the  high  efficiency  needed  for  real-time  applications  (see  Figure 
7). 

5.1  Comparison;  SeaWET  vs.  SAFENET  1 

The  following  table  summarizes  the  differences  between  SeaNET 
and  SAFENET  I: 


Table  I.  SeaHET  vs. SAFENET  I 


Parameter 
Network  Type 
Network  Speed 
Real-time  Protocol 
Message  Standard 
Cable 

Processor  Units 
Architecture 
Station  Types 

Station  Attachment 
Time  Service 


SgaMI 

IEEE  802.6 
4/16  Mbps 

ISO  8802/2  Class  I 
NMEA  0183 
STP  /  Fiber  Optic 
PC,  PC/AT 
Single  Ring 
Single  Attachment 

NWC 

Station  Local, 
Non-synchron i zed 


SAFENET  I 
IEEE  802.5 
4/16  Mbps 
XTP 
(TBD) 

Fiber  Optic 
VME/Futurebus+ 
Dual  Ring 
Single  Attachment, 
Dual  Attachment 
TCU 

Network  Global, 
Synchronized 


Except  for  the  lack  of  fiber  optic  cabling  from  the  attachment 
stations  to  the  NWCs  and  the  use  of  the  PCbus  rather  than  the 
VMEbus  or  Futurebust,  the  SeaNET  stations  can  meet  all  the 
reguirements  for  SAFENET  I  single  attachment  stations  as  defined 
in  the  SAFENET  I  document.  A  PC-based  version  of  XTP  has  already 
been  developed,  as  will  be  discussed  in  the  next  section,  and  has 
been  added  to  the  Sperry  real-time  network  interface.  The  SAFENET 
global  time  service  has  not  yet  been  implemented.  Once  it  is,  the 
Sperry  units  can  also  be  updated  to  use  this  service. 

5^  Xpress  Transfer  Protocol  fXTP)  Development 

Like  the  ISO  standard  transport  protocol  (TP4)  or  DOD's 
Transmission  Control  Protocol  (TCP) ,  XTP  provides  the  user  with  the 
ability  to  establish,  manage,  and  control  connections  between  end- 
users.  Transport  protocols  provide  end-to-end  reliability  across 
any  number  of  intermediate  network  segments  and  routers. 

Unlike  TP4  or  TCP,  XTP  provides  a  number  of  new  features  which 
are  of  interest  to  the  real-time  and  system  control  communities: 
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(1)  The  transport  and  network  layers  are  combined  for  efficiency; 
both  ISO  and  IP  (DOD  Internet  Protocol)  addressing  are 
supported . 

(2)  XTP  uses  a  header/trailer  format,  rather  than  just  a  header, 
so  that  hardware  can  be  used  to  calculate  the  network  and 
transport  layer  checksums. 

(3)  Data  can  be  transferred  reliably  with  a  three-packet  handshake 
rather  than  six  as  in  TP4. 

(4)  In  addition  to  conventional  error  control  and  flow  control, 
XTP  permits  rate  control;  using  rate  control,  a  receiver  can 
restrict  a  transmitter  to  data  bursts  of  a  fixed  size  and 
frequency. 

(5)  Selective  transmission  allows  a  receiver  to  request 
transmission  of  only  lost  packets,  rather  than  the  lost  packet 
and  all  subsequent  packets. 

(6)  XTP  supports  transport-level  multicast  whereby  one  multicast 
transmission  potentially  replaces  many  unicast  transmissions; 
this  is  especially  useful  for  sensor  data  distribution,  time 
distribution,  and  event  synchronization. 

(7)  XTP  supports  both  static  and  dynamic,  deadline-driven  message 
priorities. 

(8)  XTP  is  designed  for  eventual  implementation  in  VLSI;  the 
first  chips  will  interface  directly  with  FDDI. 

The  Computer  Networks  I,aboratory  has  implemented  XTP  on  top 
of  SeaNET  using  a  25  MHz  Intel  80386,  a  PCbus  backplane,  and  both 
Proteon  and  IBM  4/16  Mbps  token  ring  interfaces.  The  next  project 
will  be  to  develop  XTP  on  top  of  FDDI  using  Motorola  68020 
processors,  a  VMEbus  backplane,  and  Martin-Marietta  FDDI  token  ring 
interfaces. 

5.3  Fiber  Optics  Investigation 

Sperry  Marine  has  investigated  fiber  optics  use  aboard  vessels 
for  several  years.  Our  optics  laboratory  has  participated  in  the 
development  of  many  sophisticated  devices,  including  fiber  optic 
gyros  and  other  fiber  optic  sensors. 

Sperry  Marine's  parent  company,  Newport  News  Shipbuilding 
(NNS) ,  is  heavily  involved  in  the  building  of  Naval  vessels. 
Because  of  the  emphasis  on  fiber  optics  in  the  U.S.  Navy,  NNS  must 
determine  ways  of  designing  and  implementing  the  new  ship-of-the- 
future  which  will  have  fiber  optic  cabling  throughout.  The 
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advantages  of  such  a  ship  would  be  realized  in  the  form  of  weight 
and  volume  savings,  noise  immunity,  security,  and  survivability  . 

A  recent  Sperry  Marine/Newport  News  Shipbuilding  report  on 
fiber  optic  networks  indicates  that  the  design  and  installation  of 
fiber  optic  network  components  is  rapidly  reaching  the  point  of 
feasibility  for  shipboard  environments.  Two  examples  of  such 
components  are  the  mil-spec  fiber  optic  cable  being  designed  by 
ATST  and  the  rugged  fiber  optic  switches  being  designed  by  Dicon. 

A  more  specific  project  has  been  undertaken  in  the  Sperry 
optics  laboratory.  A  prototype  system  has  been  set  up  to  show  the 
feasibility  of  using  standard  IEEE  802.5  fiber  optic  NWCs  and  fiber 
optic  switches  to  produce  a  reconfigurable,  redundant  fiber  optic 
network.  Currently,  the  switches  are  operated  manually  from  an 
electrical  switch  box.  The  next  step  will  be  to  automate  detection 
of  network  failures  and  reconfiguration  of  the  network  via  the 
attachment  stations.  Additionally,  an  attempt  will  be  made  to 
provide  fiber  optic  cabling  directly  from  the  attachment  station 
to  the  NWC  by  replacing  the  electrical  drivers  and  receivers  with 
their  fiber  optic  counterparts. 

5.4  Continued  SAFENET  Development 

Sperry  Marine  is  continuing  to  follow  the  development  of  the 
SAFENET  standards  by  participating  in  the  bi-monthly  meetings.  In 
addition,  design  has  begun  on  a  SeaNET-to-SAFENET  bridge  which  will 
allow  SeaNET  to  hook  up  to  ard  share  data  with  any  SAFENET  network. 
This  will  be  a  VME-based  unit  which  can  later  be  upgraded  to 
Futurebus+.  It  will  employ  both  the  SeaNET  real-time  network 
interface  software  and  XTP.  A  program  will  be  developed  which  will 
handle  the  protocol  conversions  between  the  two  networks.  This 
will  allow  the  Sperry  SeaNET-based  IBS  to  be  installed  aboard 
military  vessels  today  with  easy  expansion  to  the  SAFENET-based 
systems  as  they  become  available.  Depending  on  the  mission 
requirements,  some  vessels  may  never  need  anything  beyond  SeaNET 's 
capabilities. 

6.  INTACT  ON  FUTDRE  SHIP  DESIGN 

There  are  several  aspects  of  ship  design  that  will  be  affected 
by  integration  of  shipboard  systems  using  local  area  networks  such 
as  SeaNET  or  SAFENET.  First,  vendors  will  be  able  to  offer  turn¬ 
key  systems  which  can  literally  be  transported  and  placed  on  a 
vessel  as  self-contained  modules.  These  modules  will  be  fully 
tested  in  vendor  staging  areas  in  the  factory  and  will  offer  plug- 
an-go  installation. 

The  integration  of  displays  and  reduction  in  controls  which 
are  possible  through  use  of  these  systems  also  manifest  themselves 
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in  the  form  of  weight  and  volume  savings.  Furthermore,  the  layout 
of  consoles  can  be  better  designed.  Console  configurations  are 
more  flexible  and  can  be  designed  to  fit  the  mission  reguirements. 
They  can  also  be  designed  to  make  better  use  of  the  physical  area 
in  which  they  will  be  placed. 

One  of  the  major  impacts  will  be  on  installation  of  wiring. 
Fiber  optic  cabling  regulres  special  handling.  The  number  ot 
splices  and  connectors  must  be  minimized  in  order  to  minimize 
signal  losses.  The  splices  and  connectors  must  be  Installed 
properly  to  insure  correct  alignment  of  the  fiber.  Cable  bends 
must  not  exceed  the  minimum  bend  radius.  Special  tools  are  needed 
to  install  the  splices  and  connectors,  and  to  test  for  proper 
operation  following  installation.  The  shipboard  environment  is 
certainly  not  the  best  for  accomplishing  this  task,  especially  with 
its  maze  of  bulkheads  and  tight  spaces.  However,  with  the  proper 
planning  and  design,  and  with  proper  choice  of  equipment,  these 
obstacles  can  be  overcome. 

The  advantages  of  fiber  optic  cabling  greatly  outweigh  the 
disadvantages.  Where  weight  and  volume  is  saved  through  the  use 
of  this  cable,  men  and  supplies  can  be  increased.  The  noise 
immunity  will  virtually  eliminate  data  errors  caused  by  such 
disturbances.  The  lack  of  radiated  noise  will  make  communications 
more  secure.  As  higher  speed  communications  capabilities  are 
implemented,  the  fiber  optic  cabling  system  will  be  ready  to 
support  the  additional  bandwidth. 

7 .  CONCLOSIOM 

Sperry  Marine  has  successfully  implemented  real-time  shipboard 
communications  in  its  SeaNET  token  ring  network,  SeaNET  provides 
a  high  speed  data  highway  which  enables  the  integration  of 
shipboard  navigation,  ship  control,  and  shipboard  communications 
equipment.  The  system  is  based  on  established  hardware  and 
software  standards.  Sperry  Marine's  Integrated  Bridge  technology 
has  received  rapid  acceptance  by  both  the  commercial  customers  and 
international  marine  regulator  bodies,  such  as  Det  Norske  Veritas 
(Norway) .  Recent  evaluations  indicate  that  Sperry  Marine’s  SeaNET- 
based  Integrated  Bridge  technology  offers  Navy  and  Coast  Guard 
vessels  improved  performance,  greater  design  flexibility  and  the 
ability  to  keep  pace  with  the  advancements  in  shipboard  systems. 
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INTBGRATBO  PLATFORM  HAHAGEMENT 
THE  SOFTVAKE  CHALLENGE 


by  Clive  HcNab  and  Gary  Freestone 
Vosper  Thomycroft  (UK)  Liaited 


1.  ABSTRACT 

This  paper  described  the  challenges  facing  the  software  engineer 
implementing  an  Integrated  Platform  Management  System.  Vosper  Thomycroft 
have  designed  and  implemented  for  the  Single  Role  Hinehunter  the  only  front 
line  Integrated  System,  where  the  vessel's  command,  control  and  machinery 
platform  make  available  various  types  of  common  information,  eg  ship  speed 
and  ship  position,  useful  for  the  efficiency  of  both  systems. 

The  Single  Role  Minehunter's  Integrated  System  improves  efficiency  by 
allowing  more  flexible  manning  levels,  through  the  introduction  of  automatic 
control  techniques,  such  as  the  Ships  Positional  Control  System  (SPCS). 

In  the  continuing  search  for  greater  efficiency,  warship  developers  will 
increase  the  level  of  automation  even  further. 

While  Integrated  Systems  offer  improvements  in  the  operational 
flexibility  of  a  warship,  it  increases  the  demands  placed  upon  the  developers 
of  such  systems,  most  notably  software  engineering.  These  engineers  are 
faced  with  the  task  of  designing  the  more  automated  systems  which  are 
becoming  increasingly  large  and  highly  complex. 

2.  INTRODUCTION 

The  increases  in  automation  of  the  machinery  platform  have  arisen  as  a 
response  to  the  need  to: 

reduce  manpower  costs 
reduce  operational  overheads 
improve  operational  effectiveness 
counter  skill  shortages 

In  addition  where  any  automation  is  introduced  into  the  naval 
environment  there  are  the  general  naval  criteria  to  consider,  that  is  to 
provide  systems  which  have: 

low  through  life  cost 
high  reliability 
high  availability 
high  survivabili ty 
high  maintainability 
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3.  BACKGROUND 

3.1  General 

Warships  which  are  just  entering  service  with  the  Royal  Navy  are  £itte(J 
with  machinery  platforms  that  have  a  greater  part  of  their  function  provided 
by  software.  Examples  include  the  Type  23  frigate  and  the  Sandown  class  of 
Single  Role  Mine  Hunters  (SRHB).  The  facilities  provided  by  the  platforms 
are  made  up  of  several  systems  such  as  propulsion,  electrical  power, 
auxiliary  and  ancillaries.  Individual  functions  within  each  of  the  systems 
are  often  based  upon  microprocessor  technology.  One  such  common  example  is 
the  engine  controllers  of  the  propulsion  system. 

It  is  the  software  in  conjunction  with  the  electrical  interfaces  which 
change  to  define  the  functions  needed  for  the  application  of,  for  instance, 
engine  control. 

Even  on  these  recent  machinery  platforms  the  systems  are  not  entirely 
Integrated.  For  the  Type  23  frigate  the  current  arrangement  is  one  in  which 
the  main  power  system  Han  Machine  Interface  (HHI)  is  located  adjacent  to  the 
other  platform  HMIs,  with  integration  of  the  systems  being  confined  to  the 
secondary  surveillance  function. 

Other  recent  arrangements,  for  example  the  SRHH,  use  a  common  data 
highway  to  link  the  propulsion  (manoeuvring)  system  with  the  command  system, 
but  even  here  centralised  control  from  one  point  is  not  a  feature. 

3.2  Integration  Options 

For  future  platforms,  as  with  the  current  ones,  the  options  available  to 
the  procurement  agencies  are  a  balance  between  technical  risk  and  operational 
costs.  The  choices  can  be  summarised  as: 

(1)  Discrete  System:  this  is  generally  considered  to  be  current 
practice  whereby  the  systems  operate  independently,  although  the 
HMIs  may  be  located  adjacent  to  each  other  in  the  machinery  control 
room.  Figure  2.1  shows  the  arrangement  of  a  typical  discrete 
platform. 
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Figure  2.1  -  Discrete  Platform  Management  System 
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(2)  Integrated  Platfore  Manageeent  Systee:  here  the  machinery  systems 
are  linked  to  each  other  via  a  machinery  management  highway  (Figure 
2.2).  Control  and  measurement  of,  for  example,  the  propulsion  and 
electrical  systems  can  be  accomplished  through  a  common  HMI 
workstation.  Vhere  necessary,  the  machinery  platform  may  exchange 
information  with  other  ship  facilities  via  a  communication  gateway. 


Figure  2.2  -  Integrated  Platform  Management  System 


(3)  Integrated  Ship  Management  System:  the  machinery  systems  are 

linked  to  each  other  and  all  other  systems  via  a  ship's  management 
highway  (Figure  2.3).  The  entire  ship's  automatic  facilities  can 
be  accessed  through  a  common  HMI,  and  the  functions  accessible  are 
not  confined  to  the  machinery  systems. 


Figure  2.3  -  Integrated  Ship  Management  System 


The  discrete  system  reflects  current  naval  practice  and  is  clearly 
viable  but  achieves  the  least  reduction  in  manpower  or  improvement  in 
operational  effectiveness.  At  the  other  extreme  the  integrated  ship 
management  system  can  yield  the  greatest  benefits,  but  it  also  carries  the 
greatest  technical  risk.  For  the  software  engineering  task  this  can  be 
summarised  as: 

(1)  Procurement  difficulties  in  partitioning  the  boundaries  of 
responsibility  to  suppliers. 
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(2)  Project  management  difficulties  in  measuring  and  controlling  a 
large  software  project. 

(3)  Test  and  acceptance  complications  caused  by  the  very  nature  of  the 
product,  ie  real  time  embedded  systems. 

(4)  Commissioning  complications  caused  by  the  need  to  undertake  setting 
to  work  activities  in  parallel. 

(5)  Maintenance  complications  caused  by  the  need  to  validate  changes 
vithin  the  framework  of  a  large  system. 

(6)  Extended  risk  as  the  suppliers  depend  on  each  other,  and  failure  of 
one  to  meet  their  requirement  could  impact  on  the  other  suppliers' 
performance. 

The  Integrated  Platform  Management  System  (IPMS)  and  Integration  Ship 
Management  System  (ISMS)  although  suffering  similar  complications,  differ  in 
the  scale  of  the  software  challenge.  IPMS  recognises  that  the  information 
exchanged  between  the  platform  and  the  ship's  highway  can  be  limited,  and  as 
a  consequence  achieves  a  substantial  reduction  in  risk.  Table  3.1  which 
follows  illustrates  the  possible  systems  that  an  Integrated  Platform 
Management  System  might  contain. 


TABLE  3.1 

POSSIBLE  SYSTEMS  VITHIN 
AN  INTEGRATED  PLATFORM  MANAGEMENT  SYSTEM 


MACHINERY  CONTROL  AND  SURVEILLANCE 

PROPULSION 

ANCILLARY 

AUXILIARY 

Main  Engines 

Shafts 

Clutches 

Couplings 

Gearboxes 

Sea  Water  System 
Fuel  Oil  System 
Lubrication  System 

Chilled  Water  System 
Fresh  Water  System 

Air  System 

ELECTRICAL  POWER  MANAGEMENT 


Generation 
Distribution 
Propulsion  Motors 
Conversion 
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STEERIHG  AMD  STABILIZATION 


Rudder  Control 

Stabilizers 

Ballast 


DANAGB  CONTROL  AND  SURVEILLANCE 


NBC  Detection 
Fire  Detection 
Flood  Detection 
Fire  Control 
Ventilation  Control 


While  IPHS  does  reduce  the  size  of  the  task  it  still  contains  a  large 
amount  of  software.  Already  the  expectations  of  software  as  a  method  for 
changing  systems  easily  and  cheaply  have  not  always  been  fulfilled.  The 
questions  facing  both  platform  suppliers  and  procurement  agencies  is,  how  can 
the  software  be  controlled  in  terms  of  both  risk  and  cost? 

4.  REDUCING  COST  AND  RISK 


4.1  General 


The  production  of  an  IPHS  will  be  a  highly  complex  task  involving  tens 
of  thousands  of  man  hours  of  effort.  The  management  of  this  task  in  terms  of 
delivering  on  time,  within  budget  and  meeting  the  expectations  of  the 
customer  is  difficult. 

Some  of  these  aspects  are  described  as  follows: 

4.2  Risks  in  Procurement 

The  functions  needed  for  effective  operation  need  to  be  adequately 
specified  when  procuring  the  systems  from  separate  suppliers.  One  frequently 
used  method  is  to  Identify  the  behaviour  in  terms  of  a  textual  requirement. 
This  is  used  to  partition  up  the  system  into  separate  procurement  packages. 
These  requirements  can  be  difficult  to  check  and  nay  be  contradictory 
especially  around  the  interfaces  between  systems,  for  example  the  propulsion 
and  electrical  systems. 

To  overcome  some  of  these  potential  engineering  difficulties  the 
customer  is  adopting  more  rigorous  technical  methods  in  their  specifications. 

4.3  Project  Managenent  Difficulties 

Project  Management  of  a  software  task  as  large  as  an  IPHS  is  inherently 
difficult.  Within  such  a  system  there  may  be  thousands  of  interfaces  and 
functions  to  be  specified  and  produced.  In  addition,  the  task  carries  a 
major  overhead  as  a  large  number  of  software  engineers  will  be  involved. 
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Production  of  code  has  often  been  perceived  as  the  main  focus  of  project 
managements'  attention,  particularly  when  timescales  for  delivery  are  tight. 
This  has  encouraged  the  emphasis  avay  from  performing  a  thorough  analysis  and 
design. 

Recent  figures  indicate  that  64X  of  software  errors  are  introduced  in 
the  analysis  and  design  phases,  and  of  these  some  45X  remain  undetected  until 
customer  acceptance.  This  of  course  is  a  major  source  of  customer 
dissatisfaction.  In  addition  the  cost  of  error  correction  increases  the 
later  in  the  software  life  cycle  the  errors  are  discovered.  For  the 
platforms  currently  entering  service,  such  as  for  example  SRMH,  the  trends 
have  been  towards  placing  more  emphasis  on  the  analysis  and  design  phases, 
where  error  correction  is  relatively  cheap.  For  project  management  the 
difficulty  with  this  approach  has  been  the  visibility  of  progress.  To 
overcome  this,  most  current  methods  use,  as  a  means  of  assessing  progress, 
the  validation  and  verification  milestones  at  the  end  of  each  development 
phase,  for  example  analysis,  design  and  coding. 

4.4  Teatimt  Complications 

The  large  software  systems  that  make  up  the  platform  will  contain 
software  which  is  time  critical  in  responding  to  events  from  the  environment, 
for  example  a  surveillance  system  will  need  to  stop  an  engine  should  the  oil 
pressure  fail.  These  event  stimulus  may  result  in  complex  scenarios  for  the 
system  to  manage.  Testing  for  all  eventualities  is  therefore  seen  as 
essential,  but  this  is  seldom  achieved  due  to  the  complexity  of  the  task. 
Figure  3.1  shows  the  traditional  testing  based  on  a  'bottom  up'  technique, 
starting  with  low  level  unit  testing  through  software  integration  testing, 
system  Integration  and  finally  acceptance  testing. 

Incremental  integration  is  a  common  strategy  used  where  each  function 
and  code  path  is  tested  as  the  software  is  constructed. 

The  'bottom  up'  technique  attempts  to  demonstrate  that  the  software 
products  from  each  development  phase  satisfy  the  requirements.  It  can  be 
characterised  by: 

(1)  Consuming  50X  of  the  time  and  resources  of  a  project. 

(2)  It  is  difficult  for  management  control. 

(3)  It  involves  large  quantities  of  low  quality  testing. 

(4)  It  terminates  when  the  project  runs  out  of  patience. 

A  further  feature  of  this  system  development  is  the  lack  of  traceability 
of  the  initial  customer  requirements  which  results  in  the  lower  level  tests 
being  performed  against  an  interpretation  of  the  requirement  that  is  the 
result  of  two  to  three  layers  of  abstraction.  This  results  in  deviations 
from  the  requirement  only  being  discovered  in  the  later  stages  of  the  testing 
cycle  when  they  are  mote  expensive  to  rectify. 
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Figure  3.1  -  Software  Testing  Cycle 


One  way  to  counter  these  deficiencies  is  to  have  full  traceability  of 
requirements.  This  vould  enable  the  lover  level  of  testing  to  be  performed 
with  the  confidence  that  specified  customer  requirements  have  been  met. 

4.5  Coamissioning  Complications 

The  IFHS  may  contain  systems  produced  by  separate  suppliers  which  are  to 
be  integrated  to  provide  the  facilities  of  the  platform  as  a  vhole.  During 
this  risky  integration  phase,  extensive  delays  to  the  ship's  programme  may 
occur,  should  any  one  of  the  separate  suppliers  encouter  unforseen 
difficulties.  The  dependency  of  the  suppliers  on  each  other  is  therefore  a 
major  consideration  where  for  example,  one  system  requires  data  from  another 
to  successfully  operate.  One  very  common  problem  area  could  be  the  control 
of  message  compatibility  along  the  machinery  management  highway. 

One  of  the  most  successful  ways  of  addressing  this  problem  has  been  for 
the  shipbuilder  to  adopt  the  role  of  machinery  management  highway  custodian. 
This  role  Involves  integration  planning,  and  risk  assessment  as  well  as 
defining  interface  protocols. 

4.6  Maintenance  Complications 

A  potential  drawback  with  an  IPHS  is  when  changes  occur  to  a  particular 
system.  Consideration  needs  to  be  made  as  to  how  such  changes  affect  other 
systems  and  hence  the  platform  as  a  vhole. 
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Good  design  practices  such  as  loose  coupling  and  data  hiding  principles 
can  go  a  long  way  to  solving  this  potential  problem,  in  conjunction  with  the 
continuation  of  the  role  of  machinery  management  highway  custodian. 

4.7  Extended  Risk 

Outside  the  scope  of  this  paper  as  the  main  controlling  method  is 
probably  cost  penalty. 

4.8  System  Hethodoloiiy 

The  requirements  for  software  that  has  real  time  responses,  highly 
concurrent  processing  and  unique  hardware  interfaces,  which  are  all  aimed  at 
a  target  system  that  does  not  support  the  development  environment,  add  up  to 
a  remarkably  complex  software  task.  If  you  then  add  in  formal  documentation 
and  methodology  requirements,  plus  maintenance  for  a  one  to  thirty  year 
product  life  cycle,  you  are  looking  at  an  order  of  complexity  not  found  in 
most  previous  software  developments. 

Even  with  t!  .  discrete  platform  systems  currently  entering  service  the 
key  to  managing  this  complexity  has  been  to  develop  software  within  the 
framework  of  a  ystem  methodology.  Figure  3.2  shows  how  such  a  framework  is 
constructed,  which  includes  both  methods  and  management  control. 


eg  Procedures 
QualHy  Systems 
Life  Cycle  Systems 


/AUTOMATIC 
TOOL 

VSUPPORT/ag  Config  Management 
Method  Support 


Figure  3.2  -  System  Development  Methodology 


The  general  capabilities  that  the  system  methodology  must  have  are: 

(1)  Technical  Methods 

(a)  The  capture  of  the  requirements  precisely,  without  ambiguity 
or  duplication. 
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(b)  Traceability  of  the  requirement  throughout  the  development 
phases  of,  for  example  analysis,  design,  implementation  and 
test. 

(c)  The  flexibility  to  accept  changes  in  the  requirement  easily 
throughout  development. 

(d)  Methods  for  partitioning  the  problem  into  smaller  easier 
understood  packages. 

(e)  Tools  for  modelling  all  the  aspects  of  the  systems  behaviour, 
for  example  dynamics,  data  and  objects. 

(2)  Management  Systems 

(a)  Methods  for  validating  and  verification. 

(b)  Methods  for  measuring  and  controlling  progress. 

(c)  Guidelines  for  producing  design  and  maintenance  documentation 
to  the  required  standards. 

(d)  A  metrics  collection  system  to  improve  estimating  on  future 
projects. 

(e)  Methods  for  controlling  changes  and  baselines  issued  to  the 
customer. 

(3)  Automatic  Tool  Support 

(a)  Technical  methods  support. 

(b)  Configuration  management  support. 

a.  Technical  Methods  -  Traditional  requirement  expression  contains 
redundancy,  is  contradictory,  monolithic  and  implementational.  The  question 
often  asked  by  industry  is  "Is  this  what  the  customer  vants?"  What  is 
required  in  the  initial  stages  of  the  system  development  process  is  the 
ability  to  engineer  the  unstructured  customer  requirements  to  enable  the 
support  of  traceability  and  compliancy  throughout  the  project  life  cycle.  To 
add  to  this  problem  it  is  now  becoming  mandatory  on  more  recent  projects,  to 
demonstrate  hov  customer  requirements  have  been  met. 

The  traditional  method  of  maintaining  traceability  of  the  customer 
requirements  is  by  the  implementation  of  manual  procedures.  By  automating 
the  initial  requirements  phase,  it  allows  the  customer  requirements  to  be 
linked  to  subsequent  stages  of  the  system  development  process.  This  linking 
allows  the  dynamic  update  of  compliancy  relationships  between  the 
requirements  and  the  other  stages  of  development.  This  in  turn  enables  the 
project  managers  to  produce  compliancy  reports,  perform  impact  analysis  of 
requirement  changes  and  provides  visibility  of  progress. 

Complex  embedded  software  engineering  projects  require  a  more 
comprehensive  approach  than  in  the  early  days  of  embedded  system  development. 
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Development  teiuns  nov  replace  the  single  programmer,  vhile  structured  methods 
for  requirement  analysis,  design,  coding,  integration  and  test  augment  the 
old  seat-of-the  pants  instincts  and  knov-hov. 

For  machinery  platforms,  structured  methods  were  first  used  on  the  Type 
23  frigate  and  Single  Role  Mine  Hunter  projects  of  the  early  1980' s.  These 
methods  vere  used  with  corresponding  tool  support,  in  order  to  maximise  the 
productivity  of  the  teams  and  to  allow  them  to  remain  relatively  small  and 
efficiently  managed. 

These  structured  methods  vere  concerned  with  building  a  series  of  models 
of  the  system.  The  use  of  models  is  a  long  standing  engineering  practice 
(blue  prints,  circuit  drawings,  prototypes)  and  there  was  no  obvious  reason 
to  treat  software  engineering  any  differently. 

The  models  were  a  representation  in  miniature  of  the  system  which 
highlighted  the  most  important  issues  at  a  particular  stage  of  development. 
Different  system  development  methods  propose  different  models  but  they  all 
have  the  same  common  characteristics.  The  strategy  used  on  SRHH  was  the  Real 
Time  Structured  Analysis  and  Structured  Design  (RTSASD)  method  which  has  the 
important  advantage  of  permitting  expression  of  the  required  behaviour  of  the 
system  without  implementation  detail. 

Structured  methods  have  advantages  over  traditional  methods  in  that  the 
models  provide: 

Better  communication  through  the  use  of  graphics  with  textual 
support  and  an  hierarchic  organisation. 

Management  of  complexity  through  problem  partitioning  and 
abstraction. 

Quality  assurance  through  evaluation  criteria  and  iterative 
refinement. 

The  model  of  the  system  provides  everyone  involved  with  a  single  visible 
focus  for  understanding  and  discussion.  In  addition,  building  the  right 
sequence  of  models  provides  the  fundamental  basis  for  an  organised 
development  cycle.  From  experience  using  models  as  a  basis  means  that 
specifications  are  more  likely  to  be  partitioned,  non-redundant,  succinct, 
maintainable,  unambiguous,  testable,  comprehendable,  complete  and  consistent. 

b.  Management  Systems  -  Management  systems  are  probably  the  most 
important  aspect  of:  the  system  development  process.  They  provide  mechanisms 
for  quality  management,  progress  measurement  and  configuration  control. 

For  quality  management  the  key  to  success  is  the  ability  to  continuously 
monitor  the  software  development  process.  This  is  achieved  by  verification 
and  validation  throughout  the  software  development,  or  to  put  it  another  way, 
to  continually  ask  "Are  we  building  the  product  right?"  and  "Are  we  building 
the  right  product?" 

Most  of  the  validation  and  verification  is  achieved  using  a  technique 
known  as  the  walkthrough,  where  a  produce  of  the  development  process  is 


reviewed  by  a  group  of  interested  parties.  The  phases  of  the  software 
development  that  are  subject  to  verification  or  validation  follow  closely  the 
life  cycle  of: 

(1)  Requirements  Specification  -  The  Requirements  Specification  is 
validated  against  all  contractual  and  management  material  to  ensure 
that  it  is  an  accurate,  unambiguous  specification  of  what  is 
required. 

(2)  Structural  Software  Design  -  The  Structural  Software  Design  is 
verified  against  the  Requirement  Specification  and  Quality  material 
to  ensure  that  it  specifies  the  architecture,  control  and  data 
structure  of  the  software. 

<3)  Detailed  Software  Design  -  The  Detailed  Software  Design  is  verified 
against  the  Structural  Software  Design  to  ensure  that  it  specifies 
the  organisation  of  the  code. 

(4)  Coded  Unit  Tests  -  The  Coded  Unit  and  test  plan  is  verified  against 
the  Detailed  Software  Design  to  ensure  that  the  implementation  is 
correct  and  the  testing  is  thorough  in  all  aspects. 

(5)  Software  Integration  -  The  Software  Integration  Plan  is  verified 
against  the  test  philosophy  and  strategy  specified  in  the 
Structural  Software  Design. 

(6)  System  Integration: 

(a)  The  integrated  software  is  tested  as  a  whole  in  its 
deliverable  form,  le  firmware. 

(b)  It  is  validated  against  a  system  test  specification  which  has 
been  derived  directly  from  the  requirements  specification. 

(c)  The  system  will  be  tested  as  a  whole,  including  any  items 
other  than  software,  ie  electronics,  mechanical  items  etc. 

(d)  Functional  and  performance  criteria  form  a  major  part  of  these 
tests. 

(7)  Factory  Acceptance  -  Factory  Acceptance  Tests  are  derived  directly 
from  the  system  test  specification.  These  tests  demonstrate  to  the 
customer  that  the  system  will  fulfill  its  required  function  and 
performance. 

Various  metrics  have  been  suggested  for  measuring  software  development 
quality  and  progress,  these  range  from  the  rate  of  error  removal  through  to 
the  lines  of  code  produced.  All  these  methods  have  their  own  strengths  and 
weaknesses  but  most  of  them  rely  on  tangible  output,  ie  lines  of  code.  This 
measurement  is  seldom  adequate  for  systems  as  large  as  the  IPHS  where 
development  time  is  lengthy  before  any  code  is  generated.  One  practical  way 
to  gain  visibility  of  actual  progress  is  to  measure  the  validation  and 
verification  milestones  which  occur  throughout  the  development  cycle. 
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It  is  essential  to  have  metric  collection  programmes  which  measure 
factors  such  as  complexity,  code  size  and  software  engineering  experience,  so 
that  these  can  be  used  in  conjunction  with  software  estimation  methods,  for 
example  Constructive  Cost  Models  (COCOMO),  to  predict  more  accurately, 
delivery  dates  and  budgets  for  both  existing  and  future  systems. 

One  area  of  increasing  emphasis  is  the  need  to  produce  software  to  a 
specific  reliability  figure.  This  cannot  be  achieved  without  a  comprehensive 
metrics  programme  which  measures,  for  example,  the  error  removal  rate.  This 
particular  metric  can  be  usc^  to  predict  reliability  growth  patterns  for  the 
software. 

Finally,  the  whole  of  the  system  development  process  needs  to  be 
controlled  and  managed  to  allow  changes  to  be  implemented  with  minimal  risk. 
This  is  achieved  by  configuration  management  which  is  'the  discipline  of 
identifying  the  software  components  of  a  continuously  evolving  system  for  the 
purpose  of  controlling  changes  to  the  software  and  maintaining  integrity  and 
traceability  throughout  the  software  life  cycle'.  Configuration  management 
enables  configuration  control  to  be  implemented  which  is  'the  discipline 
which  ensures  that  proposed  changes  shall  be  prepared,  accepted  and 
controlled  in  accordance  with  set  procedures'. 

Thus  configuration  management  ensures  that  precisely  the  specified 
software  is  produced  and  issued  and  it  also  takes  the  production  process 
visible. 

As  a  minimum  the  configuration  management  process  should  provide  the 
facilities  detailed  below: 

(1)  Controlled  access  to  a  securely  held  set  of  software. 

(2)  Automatic  enforcement  of  administrative,  modification  and  quality 
control  approval  procedures. 

(3)  Administrative  support  for  QA  activities. 

(4)  Help  for  project  managers  in  establishing  and  maintaining  software 
production  procedures  and  standards. 

(5)  Help  to  project  leaders  in  organising  and  controlling  software 
production. 

The  only  constraint  is  that  the  configuration  management  production 
overhead  should  be  small  to  make  it  cost  effective. 

c.  Automatic  Tool  SupTOrt  -  Underpinning  the  technical  methods  and 
management  systems  is  the  neeo  for  a  complementary  set  of  integrated  tools. 

Having  determined  the  methods  and  techniques  to  be  used,  the  choice  of 
the  tools  to  support  them  will  be  influenced  not  only  by  their  ability  to 
support  the  chosen  method,  but  also  by  their  ability  to  interface  with  one 
another,  allowing  automatic,  safe  transitions  from  one  phase  to  the  next. 
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A  point  vorth  emphasising  is  that  the  tools  are  only  there  to  support 
the  methods.  The  success  of  producing  a  real  time  embedded  system  still 
depends  on  having  an  abundance  of  skill,  knowledge  and  creativity  in  the  team 
working  on  the  project.  The  tools  will  then  alleviate  the  tedious,  time 
consuming  aspects  of  the  work  allowing  the  system  to  be  produced  on  time, 
within  budget,  meet  the  specified  quality  standards,  and  at  the  same  time 
reduce  through  life  costs. 

Finally  in  order  to  achieve  maximum  combined  effectiveness  of  the 
methods,  tools  and  hardware  platforms,  a  rigorous  definition  of  how  they  are 
to  be  used  together  to  achieve  the  project  goals  has  to  be  produced. 

5.  POST  DESIGN  SUPPORT  (PDS) 

5.1  General 

The  technical  risk  is  significantly  lowered  once  the  new  system  has  been 
commissioned,  and  therefore  known  to  fulfill  its  requirements.  As  the  system 
enters  the  post  design  phase,  procurement  agencies  are  now  faced  with  the 
problem  of  balancing  between  costs  and  the  time  taken  to  make  a  change. 
Vhereas  previously,  during  the  design  phase  the  problem  was  one  of  balancing 
between  costs  and  technical  risks. 

5.2  Sources  of  Change 

The  sources  from  which  change  can  originate  are  summarised  as  follows; 

Rapidly  changing  technology  may  force  changes  to  Interface  software 
as  obsolete  hardware  components  are  designed  out. 

Rapidly  changing  technology  may  force  changes  to  the  software  as 
the  tools  for  supporting  the  system  become  obsolete.  Examples 
might  include  the  host  development  computer  and  software  language 
compilers. 

Requirement  changes  as  the  systems  are  used  in  new  ways  not 
foreseen  by  the  designers  but  which  improve  operational  efficiency 
even  further. 

Equipment  faults  discovered  as  the  systems  are  used.  This  may  be  a 
common  source  of  change  within  the  first  few  years  of  the  system's 
life. 

5.3  Types  of  Support 

As  discussed  previously,  the  question  facing  the  procurement  agencies 
is,  how  do  we  get  changes  done  in  a  sensible  time  frame  and  at  a  reasonable 
cost?  The  options  available  can  be  summarised  as: 

(a)  Event  Post  Design  Support:  no  specific  suppliers  are  nominated  for 
the  post  design  tasks.  As  changes  are  needed  they  are  considered 
in  isolation  and  placed  as  separate  contracts. 
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(b)  Continuous  Post  Design  Support:  dedicated  resources  are  set  aside 
by  the  suppliers  nominated  for  the  post  design  tasks.  Changes  are 
made  on  a  continuous  basis  by  a  support  team  and  software  updates 
can  be  released  periodically. 

Event  Post  Design  support  can  be  clearly  the  most  cost  effective.  It 
does  however  have  serious  drawbacks  which  are: 

original  design  team  is  disbanded  and  the  applications  knowledge  is 
lost. 

minor  changes  may  become  prohibitively  expensive  as  the  system  is 
re-learned  by  a  new  team  perhaps  for  each  change. 

minor  changes  will  take  considerably  longer. 

hardware  vehicles  for  validating  changes  to  the  software  need  to  be 
rebuilt  for  each  change. 

delivery  dates  will  be  poor  as  a  team  is  recruited  for  the  change. 

Continuous  Post  Design  Support  overcomes  these  issues  with  a  subsequent 
higher  cost  penalty  while  the  team  is  maintained  during  slacker  periods. 

Probably  the  best  solution  for  the  procurement  agencies  is  a  combination 
of  the  two  Post  Design  Support  Methods.  In  the  early  lifetime  of  the  system 
adopt  continuous  post  design,  here  the  changes  needed  will  occur  frequently 
and  be  needed  quickly.  Experience  invested  in  the  design  is  then  held  intact 
and  should  there  be  any  slack  periods  these  can  be  utilised  to  increase 
productivity,  by  for  example,  improving  documentation.  Once  the  systems  have 
matured,  and  changes  become  less  frequent  then  the  event  driven  post  design 
method  may  be  adopted.  However,  no  matter  which  method  or  combination  of 
methods  are  preferred  there  will  be  difficulty  in  maintaining  the  host 
development  computer  for  periods  of  thirty  years  and  in  keeping  engineers  who 
are  willing  to  maintain  the  older  systems. 

6.  COWCmSlOHS 

Recent  machinery  platform  systems  have  allowed  suppliers  to  prepare  for 
the  software  challenge  facing  them  when  new  more  integrated  systems  are 
procured.  The  key  to  this  preparation  has  been  the  development  of  rigorous 
system  methodologies  which  are  comprised  of  three  basic  elements;  management 
practices,  technical  methods  and  automatic  tools.  It  is  these  systems  which 
allow  the  risk  of  large  software  development  to  be  controlled.  Most  of  the 
methods  now  used  allow  the  supplier  to  focus  software  solutions  around  the 
system  requirements,  rather  than  the  technology  needed  to  implement  such 
systems.  Cost  control,  again  a  notoriously  difficult  area  in  software 
development,  has  also  improved  by  the  introduction  of  metrics  and  estimation 
systems.  In  short,  the  technical  and  cost  risks  for  producing  the  highly 
complex  software  needed  in  an  IPMS  can  be  successfully  managed  by  developing 
the  system  under  a  rigorous  environment  which  allows  adequate  specification 
of  the  boundaries  for  each  system. 
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7.  RBPKREHCBS 


(1)  Starts  Guide  (Software  Tools  for  the  Application  to  Large  Real  Time 
Systems)  -  NCC. 

(2)  Real  Time  Structured  Analysis  and  Structured  Design  for  Embedded 
Systems  -  Kennedy /Car ter  1990. 

(3)  Automation  of  Warship  Power  Systems,  1990  -  B  U  Scott  and  Geoffrey 

Bell. 

8.  TERMS 

COCOMO  :  Constructive  Cost  Model 

IPMS  :  Integrated  Platform  Management  System 

MASCOT  :  Modular  Approach  to  System  Construction,  Operation  and  Test 

MCAS  :  Machinery  Control  and  Surveillance 

MHI  :  Man  Machine  Interface 

PDS  :  Post  Design  Support 

QA  :  Quality  Assurance 

RTSASD  :  Real  Time  Structured  Analysis  and  Structured  Design 
SRMH  :  Single  Role  Mine  Hunter 
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INTEGRATED  PLATFORM  MANAGEMENT  SYSTEMS  -  GOALS  AND  OPPORTUNITIES 


by  David  Stead 
and  Denis  L.  Prager 
SEM  A  Group  Systems  Limited 


1.  ABSTRACT 

The  procurement  of  a  new  vessel  offers  a  great  deal  of  freedom  in  the  specification  of  the  ship  control 
machinery  and  associated  electronic  control  and  surveillance  systems.  The  ship  platform  system 
comprises  many  subsystems  each  of  which  is  further  decomposed  into  individual  units.  The  extent  of 
this  cauipment  is  such  that  its  operation  places  a  significant  load  on  operators  and  mainlainers  vvhich 
is  unlikely  to  be  acceptable  in  future  platforms.  Advances  in  information  technology  make  it  possib  e  to 
inteeratc  the  various  control  subsystems  so  as  to  provide  a  centralised  highly  automated  user  mlcrfaa'. 
This  will  allow  a  well  defined  interface  to  the  command  system  to  be  introduced,  manning  lewis  to  be 
reduced,  and  improvements  in  maintenance  and  reductions  in  long  term  costs  to  be  achieved.  The  paper 
considers  the  requirements  of  such  an  integrated  system,  and  highlights  the  design  and  development 
issues  that  must  be  addressed  to  meet  these  requirements. 

The  paper  surveys  the  opportunities  that  arise  in  terms  of  for  example  new  system  architectures, 
technologies,  human  factors  and  standardisation  and  argues  that  in  order  to  be  successful  such  a 
development  must  be  controlled  by  an  overall  System  Design  Authority. 

2.  INTRODUCTION 

Soma  Scientific  (formerly  C.\P  Scientific)  has  been  involved  in  integrating  platform  systems  for  the 
past  decade,  and  has  been  involved  in  platform  systems  since  CAP  Scientific's  formation. 

An  Integrated  Platform  Management  System  will  encompass  the  following  systems: 

•  Propulsion  including  propeller,  prime  mover  and  gear  box. 

•  Propulsion  Auxiliaries 

•  Auxiliaries 


Electrical  Generation  and  Distribution 


•  NBCD  control 

The  system  would  be  expected  to  be  extendable  to  include  other  ship  systems  and  in  particular  allow 
for  interfacing  to  the  Command  System. 
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In  Section  3  we  define  the  scope  of  the  Integrated  Ratform  Management  System  and  discuss  the 
requirement  in  Section  4. 

Section  5  discusses  the  current  state  of  the  platform  systems,  and  suggests  some  future  goals,  which 
should  be  used  to  measure  the  effectiveness  of  any  new  architectures. 

We  discuss  the  proposed  technological  features  of  the  system  in  Section  6  and  coitclude  by  stating  the 
need  for  a  System  Design  Authority  to  co-ordinate  and  manage  its  development. 

3.  OVERVIEW  OF  THE  PLATFORM  SYSTEMS 

The  term  'Platform  Systems’  is  generally  used  to  encompass  the  following: 

•  Propulsion  including  propeller  (controllable  or  fixed  pitch),  prime  movers,  shaft  line, 
brakes  and  gearbox. 

•  Propulsion  Auxiliaries  including  Steering  and  Stabilisation  System,  Main  Forced 
Lubrication  System,  Main  Lubricating  Oil  Transfer  and  Renovation  System,  Low  Pressure  Sea  Water 
System  and  Fuel  Supply  Renovation  and  Transfer  System. 

•  Auxiliaries  including  Refrigeration  System,  Special  Services  Air  System,  Avfuel  System, 
Desalination  System,  Sewage  System,  Fresh  Water  System  and  Bilge  and  Sullage  System. 

•  The  Electrical  systems  including  Electrical  Generation  and  Electrical  Distribution. 

•  NBCD  systems  including  Chilled  Water  System,  Ventilation  System,  Low  Pressure  Air 
System,  High  Pressure  Air  System  and  High  Pressure  Sea  Water  System. 

•  Damage  Control  including  the  state  of  the  ship  with  respect  to  fire,  flood,  smoke,  stability 
and  the  operational  state.  The  operational  state  includes  the  state  and  requirements  for  hatches  and 
other  compartment  penetrations. 

An  Integrated  Platform  System  should  therefore  cover  all  the  above  systems  but  in  addition  take  into 
account  the  future  need  to  supply  and  receive  information  from  Weapons  and  Navigation  Systems. 

4.  MOTIVATION  FOR  INTEGRATED  PLATFORM  MANAGEMENT 

The  requirement  for  an  Integrated  Platform  Management  System  is  driven  by  the  need  to  achieve 
overall  ship-wide  improvements  in  the  following  areas: 

•  Cost. 

•  Vulnerability. 

•  Safety. 

•  Availability. 

•  Flexibility 
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We  will  examine  each  o(  these  in  turn,  starting  with  cost. 

4y _ Cost 

Cost  is  almost  always  a  prime  motivation  for  change.  Clearly  the  development  and  production  costs 
of  an  Integrated  Platform  Management  System  will  introduce  an  increase  in  the  initial  ship  purchase 
price  although  there  may  be  some  scope  to  re-use  components  from  existing  equipments.  The  scope  for 
cost  benefits  therefore  derives  entirely  from  any  potential  reduction  in  through  life  costs. 

The  reduction  in  through  life  costs  would  result  from  better  utilisation  of  the  manpower,  utilisation 
of  the  longer  nvean  time  between  failure  inherent  in  the  newer  technologies  (and  allowing  a  possible 
reduction  in  spares),  and  the  ability  of  the  system  to  accommodate  change  and  expansion.  If  change  and 
expansion  can  be  achieved  with  minimal  disturbance  to  the  ship  then  this  would  have  a  significant 
effect  on  refit  costs. 

An  Integrated  Platform  Management  System  should  also  be  able  to  improve  the  performance  and  the 
economies  of  operating  the  ship  systems,  and  not  only  in  terms  of  optimising  performance  o(  a  single 
ship's  systems.  It  would  also  allow  interactions  between  various  systems  to  be  used  effectively  instead 
of  independently  operating  each  system  as  at  present.  Control  interactions  from  one  system  would 
produce  feedback  parameters  on  a  second  system.  If  these  feedback  interactions  were  anticipated  then 
the  second  system  nuiy  assist  and  certainly  would  not  resist  the  stimulus  from  the  first  system. 

The  bertefits  arising  in  terms  of  manning  depend  on  the  mode  of  operation: 

•  Normal  Operation  Use. 

•  Harbour  Watchkeeping. 

Planned  Maintenance. 

•  Breakdown  Maintenance  and  Breakdown  Manning. 

•  Training. 

•  Special  Sea  Duties. 

Table  1  gives  a  breakdown  of  typical  current  manning  levels. 

Normal  usage  relies  on  the  watchkeepers  in  the  ships  control  centre  (whether  located  in  a  specialist 
room  or  within  another  compartment),  and  roundsmen.  Currently  the  watchkeeper  is  an  experienced 
highly  trained  individual  who  has  to  scan  information  and  decide  when  the  information  deviates  from 
its  normal  position.  He  is  assisted  in  this  by  a  surveillance  system  which  annunciates  warnings. 
Corrective  action  is  not  initiated  unless  either  the  operator  notices  that  the  information  is  abnormal  or 
that  a  warning  level  has  been  exceeded.  Slow  changes  in  information  do  not  readily  trigger  the 
operator  to  take  corrective  action. 

The  Roundsman  is  similar  to  the  operator  except  that  the  collection  of  data  has  to  occur  from  a  non 
centralised  position.  He  spetrds  much  of  his  time  moving  from  one  source  of  information  to  another  source 
of  information  and  recording  the  readings.  Much  of  the  expertise  of  the  Roundsnran  has  been  dissipated. 
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Sound  often  triggered  the  Roundsman  to  instigate  an  investigation.  Similarly  the  Roundsman  would 
notice  increases  in  temperature  in  locations  where  there  were  no  sensors  and  again  instigate  an 
investigation. 

Normal  operational  use  unfortunately  covers  several  operating  modes  from  action,  through  defence 
states  to  cruising.  In  each  of  the  modes  there  are  various  operational  stales.  The  manning  levels 
through  the  slate  will  vary  enormously,  however  the  peak  occurs  during  action  states  when  man  power 
is  called  into  use  to  ensure  that  only  current  information  is  used  in  directing  the  ship  and  if  any  systems 
is  damaged  (or  fails)  the  operators  will  already  be  in  place  to  take  over  the  running  of  the  damaged 
equipment.  In  performing  the  control  role  for  the  damaged  systems  the  operators  will  have  indelibly 
noted  the  information  related  to  those  systems  and  will  continue  to  manually  update  the  information. 
This  will  enable  operation  of  the  function  in  spite  of  the  damage  to  the  system. 

When  a  ship  is  in  harbour  some  machinery  still  continues  to  run.  This  requires  the  use  of  roundsmen 
and  watchkeepers  to  ensure  that  pl.itform  systems  will  not  be  endangered.  When  entering  and  leaving 
harbour  and  during  re-fuelling  at  sea  it  is  necessary  to  call  up  "special  sea  duty  men".  These  personnel 
are  required  to  maintain  a  close  monitor  upon  certain  instrumentation  or  equipment.  The  equipment  is 
selected  such  that  if  it  failed  it  could  endanger  the  ship  if  remedial  action  were  not  immediately 
effected. 

From  the  above  discussion  it  is  clear  that  the  roles  of  the  watch  keeper  and  roundsmen  is  extremely 
diverse.  However  in  essence  their  tasks  arc  related  to  two  basic  functions: 

•  The  implementation  of  command  decisions. 

•  The  distribution  of  data. 

The  command  decision  role  consists  of  either  receiving  or  making  a  command  decision  and  then 
amplifying  this  decision  so  that  an  operator  or  the  operators  can  implement  it. 

The  distribution  of  the  data  enables  that  operator  to  either  make  his  own  command  decisions, 
implement  command  decisions  or  filter  the  information  sufficiently  so  that  it  can  be  passed  back  to  a 
superior  in  order  that  the  superior  can  evaluate  the  data  and  make  the  correct  command  decision.  The 
following  figure  shows  "Command  Decision"  implementation  and  information  filtering 
diagrammatically  and  expresses  the  amplification  of  command  decisions  and  the  filtering  of 
information. 
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Comcrund  Decision 


Information 


Key:  •  Amplification  of  command  decision  or  command  decision, 
also  assessment  of  data  and  filtering  of  information. 

Implementation  of  command  decision, 

assessment  of  data  and  filtering  of  information,  to  pass 

through  the  command  structure. 

I  Command  decision  implementation  and  Information 
*  Filtering. 

The  goal  of  the  Integrated  Platform  Management  System  therefore  must  be  to  assist  them  in  these 
tasks,  reducing  the  manpower  requirement  at  the  same  time.  It  is  clear  that  the  reliable  availability 
of  information  from  all  relevant  sources  at  a  central  position  is  the  key  to  achieving  this  goal. 
However,  a  degree  of  intelligence  must  then  be  available  within  the  computer  systems  at  the  central 
positions  to  ensure  that  the  operator  workload  doe  not  become  excessive.  Intelligence  is  also  called  for 
to  replace  the  experience  of  the  roundsman  in  fault  diagnosis  and  failure  prediction.  Having  placed 
such  a  heavy  reliance  on  the  information  system,  survivability  of  the  system  is  paramount. 

Unplanned  maintenance  causes  malfunctioning  equipment  to  be  either  shut  down  or  run  at  a  steady 
state  while  maintenance  is  achieved.  Steady  state  running  during  a  breakdown  requires  additional 
personnel  to  be  called  up  to  monitor  the  systems  to  ensure  that  no  further  damage  can  occur. 
Additionally  personnel  required  to  repair  a  breakdown  are  usually  highly  skilled  and  work  at  the 
location  of  the  breakdown  either  using  built-in  test  equipment  or  by  using  special  test  equipment. 
Current  special  and  built-in  test  equipment  usually  analyses  down  to  the  zone  of  the  fault  and  speedy 
fault  finding  still  requires  an  experienced  operator  to  operate  the  test  equipment.  The  need  tor 
unplanned  maintenance  must  clearly  be  eliminated  as  far  as  possible. 

Planned  maintenance  has  been  an  area  where  improvements  have  occurred  during  the  last  decade. 
Much  of  this  improvement  has  resulted  from  merely  liming  the  period  of  use  for  the  equipment. 
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However,  it  is  recognised  that  greater  improvements  could  be  achieved  by  condition  monitoring  and  by 
the  use  of  more  extensive  computer  based  diagnostics  aids.  These  must  be  incorporated  in  any  future 
Integrated  Platform  Management  System. 

Training  currently  requires  the  use  of  handbooks  supported  by  out-of-use  equipment.  Except  in  the  case 
of  procedural  trainers,  training  is  not  interactive  and  normal  operators  can  not  anticipate  unusual 
situations  and  their  re-actions  cannot  be  developed.  In  the  future  Integrated  Platform  Management 
System  we  can  reduce  the  Hrtte  devoted  to  off-line  training  by  incorporating  training  aids  in  the  system 
and  making  them  realistic  enough  to  train  personnel  in  coping  with  all  scenarios.  On-board  training 
makes  use  of  otherwise  wasted  time  and  i^uces  the  overall  manpower  requirement  by  saving  the 
resources  that  would  be  devoted  to  on-shoie  training. 

i2 _ Availability.  Vulnerability  and  Safety 

Availability,  Vulnerability  and  Safety  are  closely  coupled  system  parameters.  Vulnerability 
would  be  reduced  by  increasing  the  likelihood  that  any  failure  in  one  system  would  be  covered  by  the 
availability  of  an  alternative  system.  Safety  would  be  improved  in  a  similar  manner  to  vulnerability, 
except  that  the  alternative  system  would  be  active  and  checking  the  states  of  the  first  system. 

Key  factors  which  impact  upon  vulnerability  and  safety  are: 

•  Interactions  with  other  systems. 

•  Dependencies  on  other  systems. 

•  Redundancy  within  the  system. 

•  Interlocks  and  information  from  other  systems. 

Extensive  improvements  have  been  achieved  in  the  last  two  decades  by  the  use  of  interlocks  and 
redundancy.  Unfortunately  the  use  of  single  interlocks  has  resulted  in  an  increase  in  the  system 
unavailability. 

Reliability  has  been  increased  by  duplication  of  key  equipments,  however  there  has  been  an 
unfortunate  side  effect  of  drastically  increasing  costs,  not  merely  doubling  in  costs  but  often  trebling  or 
quadrupling  costs  as  the  equipment  has  to  diagnose  when  to  use  its  redundant  sections. 

Safety  has  been  increased  by  monitoring  dependencies  and  increasing  the  number  of  interlocks 
internally  and  from  other  equipments.  Accidents  still  occur  and  there  is  further  scope  for  improvement 
in  both  vulnerability  and  safety. 

The  significant  developments  in  electronic  systems  over  the  past  decade  should  enable  a  fresh 
approach  to  be  taken  in  developing  systems  that  meet  the  combined  targets  of  reliability, 
availability/vulnerability  and  safety  in  a  more  cost-effective  manner  than  in  the  past.  This  clearly  is 
a  requirement  for  future  Platform  Systems  and  can  only  be  gained  by  deploying  world-products  which 
through  their  wide  market  exposure  have  been  given  the  opportunity  to  mature  more  satisfactorily 
than  the  custom-fashioned  systems  which  have  been  deployed  to  date. 
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Flexibility 


The  previous  decade  has  also  seen  an  acceleration  in  the  rate  of  change  of  electronic  computer 
facilities.  Decisions  on  whether  to  incorporate  a  change  or  to  wait  for  further  developments  has  been  a 
major  headache.  Usually  the  incorporation  of  advances  will  necessitate  the  scrapping  or  major 
modifications  of  an  existing  system.  Architectures  for  future  Integrated  Platform  Management  System 
must  be  be  expandable  and  amenable  to  change  without  major  impact  on  the  existing  structure.  This 
points  decisively  in  favour  of  using  internationally  accepted  system  communication  and  interconnection 
standards. 


5.  MEASURING  THE  ACHIEVEMENT 

To  evaluate  any  solutions  we  must  have  a  set  of  goals  which  outlines  the  requirements.  Probably  no 
single  solution  will  satisfy  all  the  requirements,  however  a  clear  definition  of  the  goals  will  allow  the 
most  appropriate  solutions  to  be  evaluated.  This  section  is  intended  to  define  the  goals. 

The  present  systems  and  any  future  systems  will  have  the  following  critical  requirements: 

•  No  single  failure  will  fail  the  entire  system. 

•  Multiple  failures  will  leave  the  remaining  systems  operative. 

These  requirements  must  be  satisfied. 

In  the  earlier  section  we  found  the  major  cost  driver  to  be  Through  Life  Costs.  Through  Life  Costs  were 
mainly  associated  with  manning  and  with  system  enhancements.  Table  1  defines  our  current  manning 
requirements  and  Table  2  defines  a  goal  for  the  future. 

Analysis  of  the  manning  levels,  currently  in  place,  and  towards  a  future  goal  shows  that  we  will 
have  to  address  two  areas  in  particular: 

•  The  reduction  of  operator  manning  levels  required  for  special  sea  duties,  defence  watches 
and  action  stations. 

•  The  reduction  of  manning  levels  required  for  both  planned  and  unplanned  maintenance. 

The  high  manning  levels  inherent  in  special  sea  duties,  defence  watches  and  action  stations  arc  not 
actually  required  for  the  operation  of  the  system.  They  are  required  to  observe  the  system,  familiarise 
with  the  system  states  and  then  to  take  over  control  of  the  system  in  the  event  of  a  failure  or  damage. 

High  manning  levels  are  required  for  planned  and  unplanned  maintenance.  The  unplanned 
maintenance  would  be  reduced  by  more  effective  planned  maintenance  and/or  by  increasing  the 
meantime  between  failures  for  the  various  systems. 

Maintenance  manning  would  also  be  reduced  if  faults  could  be  diagnosed  more  rapidly  or  by  having 
systems  which  were  quicker  than  the  current  systems  to  repair. 
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If  system  meantime  between  failures  could  be  increased,  maintenance  manning  could  be  reduced  and 
one  of  the  reasons  for  the  standby  manning  during  special  sea  duties  etc  could  be  reduced.  It  must  be 
recognised  however  that  the  critical  systems  could  fail  because  of  information  supply  failure  and  this 
is  the  state  which  occurs  once  action  damage  has  been  sustained  by  a  vessel. 

The  second  through  life  cost  driver  was  flexibility  of  the  system  for  enhancements.  When  a  system  is 
totally  autonomous  space  and  power  are  the  only  new  requirements  imposed  on  the  ship.  However  most 
new  systems  require  information  or  will  modify  the  information  supplied  from  other  existing  systems. 
Table  3  shows  the  current  situation  for  interactive  systems  and  a  goal  for  future  systems. 

One  of  the  required  cril'ria  for  any  design  is  minimising  vulnerability.  To  discuss  vulnerability  it  is 
necessary  to  have  a  definition  of  its  meaning.  We  would  propose  the  following  sub-set  in  any  definition: 

"Minimising  the  number  of  systems  effected  if  one  system  is  damaged”. 

Some  systems  currently  only  have  local  controls,  hence  there  are  only  vulnerable  to  local  damage. 
Many  systems  have  local  and  remote  controls,  in  these  cases  damage  in  two  locations  could  effect  that 
single  Plant. 

Future  vessels  are  anticipated  to  reduce  manning,  and  with  this  reduction  in  manning  it  will  not  be 
possible  to  have  as  many  roundsmen  and  hence  remote  control  will  become  more  prevalent. 

Most  remote  controls  have  currently  been  concentrated  in  a  single  control  compartment.  The  loss  of 
this  compartment  would  result  in  widescale  loss  of  remote  control.  All  plant  could  be  controlled  from  its 
local  positions  however  coordination  and  manning  levels  would  have  to  increase  drastically  from  a 
single  action.  With  respect  to  our  definition,  the  number  of  systems  affected  if  the  remote  control 
location  were  damaged  and  there  is  only  a  single  remote  control  position,  this  configuration  maximises 
vulnerability  and  is  therefore  highly  undesirable. 

Table  4  shows  the  current  vulnerability  and  a  desired  goal. 

Manning  levels  both  in  terms  of  operability  and  maintainability  are  a  function  of  many  variables 
Table  5  shows  the  variables  for  both  operator  and  maintainer.  The  table  shows  the  functions  that  could 
be  modified  to  affect  the  manning. 

Safety  has  already  been  given  a  high  priority  on  present  day  vessels.  The  safety  of  future  systems 
and  vessels  should  not  be  any  less  than  current  safety  standards. 

6.  TECHNOLCX3IES  FOR  INTEGRATED  PLATFORM  MANAGEMENT  SYSTEMS 

Our  study  has  shown  that  there  are  a  number  of  key  target  improvements  that  are  essential  to 
properly  benefit  from  the  development  of  Integrated  Platform  Management  Systems.  We  summarise 
these  first  before  discussing  their  implementation. 

6J _ Key  Targets 


Manning 
a.  Operators 
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•  Increase  the  amount  of  automated  surveillance  and  ensure  the  surveillance  is  cognisant  of 
the  ships  operating  state  and  the  trip  values  that  should  be  representative  of  that  state. 

•  Reduce  the  number  of  operator  tasks. 

•  Reduce  the  complexity  of  the  tasks  and  allow  a  lower  skilled  operator. 

•  Reduce  the  number  of  standby  operators  necessary  and  still  ensure  that  failure  or  damage 
does  not  endanger  operations. 

•  Decrease  the  training  time. 

b.  Maintainers 

•  Ensure  that  the  systems  are  engineered  such  that  the  components  can  be  replaced  more 
quickly  than  is  the  current  practice. 

•  Enable  faster  diagnosis  of  the  failed  components  even  with  a  lower  skilled  operator. 

•  Improve  the  evaluation  of  the  effective  duty  time  that  any  equipment  has  sustained  in 
order  to  enable  increased  times  between  maintenance. 

Vulnerability 

•  Decrease  the  vulnerability  caused  by  the  loss  of  the  remote  control  station. 

Expandability  and  Flexibility 

»  Reduce  the  changes  to  hardware  and  wiring  on  existing  systems  when  new  systems  have  to 

be  introduced. 

•  Reduce  the  modifications  necessary  to  existing  systems  to  enable  data  to  be  extracted  from 
those  systems  for  any  new  systems. 

The  following  section  describes  how  these  targets  may  be  met. 

62 _ Meeting  the  targets 

Vulnerability 

Our  vulnerability  target  requires  that  we  reduce  the  susceptibility  of  the  system  once  the  remote 
control  position  is  lost.  Our  options  are  as  follows; 

•  Remove  the  remote  control  position  (this  is  not  a  viable  option  as  it  conflicts  with  the  need 
to  reduce  manning). 


•  Distribute  the  remote  control  position  (again  this  is  probably  not  a  viable  option  as 

distributing  the  remote  control  position  would  increase  the  number  of  operators). 


•  Create  an  alternative  remote  control  position  to  take  over  in  the  case  of  loss  or  damage  to 

the  first  control  position. 

Most  of  the  control  and  surveillance  data  supplied  by  auxiliary  systems  is  digital  and  has  lovif  data 
rate.  Currently  it  is  often  supplied  by  direct  wiring  from  the  local  control  panel  to  the  remote  control 
panel.  Each  of  the  pieces  of  information  is  contain^  as  a  single  signal,  and  each  system  is  managed  as 
an  entity.  Figure  1  shows  the  current  configurations.  Figure  2  shows  the  same  architecture  but  with  a 
second  remote  control  position. 


RP  =  Remote  Position 


LP  =  Local  Position 


Figure  1 ,  Current  Local  and  Remote  Control  and  Surveillance 


The  cost  of  increasing  any  system  by  this  Figure  2  will  be  prohibitive  as  it  would  require  beltveen 
1,000  and  10,000  cable  cores. 
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Any  system  to  provide  a  second  remote  system  must  therefore  be  linked  via  a  multiplex  data  link, 
which  may  be  implemented  for  example  as  a  Local  Area  Network.  Figure  3  shows  a  suitable 
configuration.  The  complexity  of  the  electronics  in  the  local  position  and  at  the  remote  position  has 
increased.  Each  position  now  includes  a  multiplexer  and  de-multiplexer  for  the  data  and  then 
conversion  from  the  multiplexed  dat.'.  to  the  communications  driver. 


Figure  3.  Future  Local  and  Remote  Control  using  a  Multiplexer  Architecture 


This  architecture  efficiently  provides  data  paths  for  local  position  plant  data  along  2  independent 
routes  to  2  (or  more)  remote  stations.  If  a  ring  network  is  used,  there  is  further  scope  for  path  redundancy 
in  that  a  ring  breakage  in  each  ring  could  be  tolerated. 

Flexibility  and  Enhanceabiiity 

Our  goals  for  flexibility  and  enhanceabiiity  arc  to  reduce  the  amount  of  hardware  change  necessary 
when  a  new  system  is  introduced  and  to  reduce  the  amount  of  modification  necessary  within  the  existing 
systems. 

If  hardware  changes  arc  to  be  minimised  then  existing  interfaces  must  be  flexible  enough  to 
accommodate  change.  This  constrains  us  to  using  a  multiplex  data  link,  such  as  the  Local  Area  Network 
proposed  above  to  link  the  Local  and  Remote  Positions.  It  may  be  acceptable  for  plant  transdua’rs  to  lx- 
connected  to  the  Local  Panel  via  discrete  links,  but  if  transducers  themselves  were  intelligent  and 
connected  to  the  Local  Panel  via  a  multiplex  digital  link  then  this  would  allow  for  even  greater 
flexibility.  It  should  be  noted  that  additional  Local  Positions  can  be  added  to  the  main  network  with 
minimal  hardware  impact,  as  can  new  external  system  interfaces,  for  example  to  a  Command  System, 

A  common  requirement  for  change  is  for  an  additional  item  of  data  to  be  monitored  by  the  system. 
Future  platform  management  systems  need  to  be  far  more  tolerant  to  such  changes  which  should  be 
possible  without  major  software  upgrade  and  achievable  during  in-service  operation.  There  are  of 
course  complex  configuration  management  problems  which  need  to  be  taken  into  account  if  this  degree  of 
adaptability  is  to  be  provided.. 
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Although  standards  already  exist  for  various  types  of  multiplex  data  link  the  format  of  the  data 
within  the  data  links,  in  the  majority  of  cases,  have  not  agreed.  To  achieve  the  desired 
flexibility  and  expandability  would  require  not  only  that  the  data  link  be  defined  but  also  the  format 
of  the  messages  to  be  transmitted,  ft  is  essential  that  the  data  link  standard  employed  is  one  that  has 
been  adopted  widely  within  the  international  community  so  that  ite  maturity  and  the  level  of  support 
given  to  it  is  adequate. 

Reducing  the  manning  of  any  future  vessels  will  depeitd  on  reducing  the  number  of  both  operators  and 
maintainers. 

a _ Qperators.Our  printary  objective  is  to  reduce  the  number  and  complexity  of  tasks 

performed  by  operators.  The  history  of  Platform  System  automation  shows  that  most  effort  has  been 
concentrated  on  producing  a  centralised  surveillaitce  system  leaving  many  control  tasks  as  manual 
activities.  This  has  allowed  some  reduction  in  the  numbCT  of  operators,  but  very  little  has  been  done  to 
assist  in  interpreting  the  information  that  is  presented  to  the  operator  by  the  support  systems. 

To  further  reduce  the  centralised  operators  tasks  it  will  be  necessary  to  provide  a  level  of  data 
interpretation  so  that  information  that  it  outside  the  norm  is  presented  to  him  as  a  priority,  and  the 
norm  is  context  sensitive.  Such  systems  are  already  well  advanced  in  the  avionics  field. 

Highlighting  the  problem  areas  to  the  operator  will  reduce  the  operator’s  workload.  The  operator 
will  still  have  to  decide  upon  the  correct  procedures  to  correct  the  problem.  To  lower  the  skill  levels  of 
the  operator  it  is  necessary  to  advise  a  lesser  skilled  operator  on  the  probable  correct  remedial 
strategy.  These  advice  systems  are  an  extetrsion  of  the  knowledge  based  systems  which  are  already 
becoming  widely  used  on  titany  industrial  survcillatKe  systems. 

During  the  previous  decade  many  of  the  more  complex  or  fast  control  functions  have  been  automated. 
The  simpler  start/stop  routines  have  been  left  unaltered.  Most  of  these  require  very  little  logic  to 
decide  when  to  start  and  when  to  stop  or  when  to  switch  to  a  second  system.  If  these  unsophisticated 
systems  are  automated  then  again  the  operator's  workload  could  be  reduced.  Even  if  the  task  could  not 
be  removed  from  the  operator,  action  from  the  operator  could  be  prompted  by  the  system  to  reduce  the 
complexity  of  the  operator’s  tasks. 

When  faults  develop  on  our  current  complex  platform  systems  it  is  often  difficult  for  the  operator  to 
appreciate  the  consequences  of  the  fault.  Evaluating  the  options  open  to  him  and  making  the  correct 
decision  to  effect  corrective  action  requires  skill  and  training.  Usually  not  all  the  options  are 
appreciated  by  the  operator  and  often  not  all  the  consequences  are  foreseen.  A  simple  solution  is  to 
provide  a  list  of  the  options  available,  and  the  consequences  for  each  of  those  options.  If  any  of  the 
options  required  further  actions  then  these  actions  should  also  be  listed  within  the  option. 

One  of  the  problems  that  arises  from  the  reduction  in  the  role  of  the  Roundsman  rvill  be  that 
problems  cannot  be  recognised  until  specific  sensors  are  triggered.  These  can  be  thermal  sensors,  thermo¬ 
couples  or  smoke  detectors.  The  problem  with  this  type  of  sensing  is  that  it  is  triggered  only  once  a 
problem  has  become  critical.  The  Roundsman  often  detected  problems  before  they  became  critical.  He 
would  notice  anomalous  hotspots  or  sounds.  A  means  will  have  to  be  devised  for  duplicating  this  role  of 
the  Roundsman. 

A  generalised  surveillance  system  would  have  to  be  created  covering  the  whole  of  a  ship’s 
compartment.  One  generalised  system  could  be  an  infrared  picture  of  the  whole  compartment.  The 
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thermal  signature  of  each  piece  of  equipment  in  the  various  running  modes  would  be  identified.  If  the 
thermal  signature  deviated  from  an  expected  signature  then  the  operator  could  be  triggered  into  calling 
extra  manpower  to  investigate  the  problem. 

A  simple  two  dimensional  picture  of  the  compartment  could  provide  sufficient  data  to  prove  that  a 
Roundsmen  was  required  for  an  investigation.  A  more  productive  approach  could  be  to  build  a  three 
dimensional  image  and  collate  the  three  dimensional  image  with  various  operational  information 
within  the  plant  management  system.  The  temperature  at  a  particular  power  setting  or  operational 
mode  would  be  registered  as  a  norm.  Deviation  from  the  norm  would  be  used  to  trigger  the  operator  into 
instigating  some  action.  Conventional  closed  circuit  television  monitoring  is  also  a  viable  operator  aid. 

An  area  which  requires  considerable  improvement  is  that  of  the  human<omputer  interface.  Various 
types  of  flexible  display  system  have  been  tried  during  the  past  decade.  Touch  screens,  flexible 
keyboards,  reconfigurable  function  keys,  tracker  balls  and  light  pens  are  all  tools  in  the  armery. 
Windowing  and  pull-down  menus  are  likely  to  be  a  feature  of  any  future  systems.  It  is  also  essential 
that  the  operator  be  given  the  freedom  to  configure  the  formats  of  displays  to  his  requirements  so  that 
the  on-line  modification  of  mimic  diagrams,  for  example,  is  a  facility  which  will  become  the  norm. 

In  summary  the  operators  tasks  would  be  reduced  by  following  the  following  the  strategies: 

•  Increasing  the  sophistication  of  the  surveillance  system  including  data  filtering  and 
interpretation. 

•  liKreasing  the  coverage  of  the  control  systems  such  that  the  simple  systems  are  also  within 
the  scope  of  the  system. 

•  Prompting  the  operator  with  suggested  actions  during  normal  activities  to  ensure  effective 
utilisation  of  equipments. 

•  Prompting  the  operator  with  suggested  remedial  actions  oiKe  a  fault  has  been  recognised  or 
has  been  recognis^  as  developing. 

•  Replacing  some  of  the  Roundsman’s  monitoring  role  with  a  general  surveillance  facility. 

•  Providing  an  effective  and  efficient  human-computer  interface. 

b.  Maintainers.  The  following  aspects  require  improvement: 

•  Ease  of  repair. 

•  Improved  diagnostics. 

•  Improved  life  prediction. 

Improvements  in  ease  of  replacement  of  components  have  already  occurred  during  the  past  decade. 
Modularisation  and  better  selection  of  line  replaceable  items  have  enabled  mean  time  to  repair  to  be 
reduced.  Unfortunately  connectors,  backplanes  and  assemblies  have  as  yet  not  succumbed  to  the  same 
improvement.  These  areas  will  require  effort  to  reduce  the  mean  time  to  replace  these  items. 
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Built  in  test  equipment  has  improved  the  location  of  faults.  During  the  past  decade,  built  in  test 
equipment  has  often  used  spare  processing  power  to  find  or  indicate  the  failed  component.  This 
philosophy  ignores  external  indications  that  can  help  diagnose  the  fault  and  the  system  also  fails  once 
the  processor  or  its  power  supply  has  failed. 

Highly  reliable  (and  independent)  built  in  test  equipment  would  increase  the  cost  of  the  unit; 
however  the  independent  BITE  could  receive  external  interfaces  information  which  when  collated 
would  give  a  much  more  accurate  fault  finding  picture.  This  in  turn  would  give  a  higher  probability  of 
diagnosis  and  remove  some  of  the  need  for  the  highly  skilled  maintainer. 

Prediction  of  the  safe  life  expectancy  of  a  component  has  until  now  been  totally  statistical.  A  life 
expectancy  has  assumed  the  stress  levels  and  has  always  had  to  err  on  the  side  of  caution;  that  is  the 
highest  stress  levels  normally  attainable  are  assumed  to  be  ones  to  which  the  component  has  been 
continually  subjected. 

The  duty  cycle  and  power  setting  levels  in  related  systems  and  dependent  systems  are  now  available 
within  the  surveillance  system.  This  data  is  available  for  life  expectancy  calculation.  Using  these 
monitored  parameters  and  the  same  equations  as  the  previous  statistical  predictions  a  much  better  life 
prediction  can  be  calculated. 

Some  systems  have  a  signature  parameter.  This  signature  parameter  can  be  used  to  indicate  if  a 
system  has  approached  the  end  of  its  safe  operating  life.  Some  signature  work  has  already  occurred  but 
results  to  date  have  not  been  very  promising. 

The  present  most  likely  route  appears  to  be  extended  life  prediction  via  the  use  of  measured  duty 
cycles.  The  work  has  already  started  on  the  more  costly  systems  where  extending  the  time  of  use  will 
save  on  early  unnecessary  replacement.  This  same  trend  will  have  to  be  extended  to  the  less  expensive 
items  if  maintenance  times  and  utilisation  are  to  be  increased. 

A  Maintainer  facility  in  a  Platform  Management  System  would  enable  the  collation  of  related  duty 
cycles  and  allow  the  maintainer  to  be  directed  to  the  most  appropriate  items  for  periodic  maintenance 
duties. 

7.  MANAGING  THE  DEVELOPMENT  OF  FUTURE  SYSTEMS 

A  future  Integrated  Platform  Management  System  poses  new  management  challenges.  The  range  of 
engineering  disciplines  involved  is  wide  embracing  amongst  others  mechanical,  electrical,  electronic, 
control  and  software  fields.  To  be  successful  system-wide  considerations,  for  example  relating  to 
reliability,  maintainability,  and  availability  must  take  precedence  over  individual  plant  or  sub¬ 
system  factors.  By  its  very  nature  an  Integrated  Platform  Management  System  relies  upon  the  flow  and 
collation  of  information  from  many  sources,  generally  under  the  control  of  different  manufacturers. 
Parameters  which  are  critical  to  the  operation  of  a  sub-system  are  often  totally  unimportant  withi., 
the  context  of  operating  a  total  platform  and  vice  versa.  The  trade-offs  to  be  made  are  numerous  and 
complex. 

This  paper  calls  for  standardised  interfaces  for  the  various  systems.  These  interlaces  would  have  to 
be  implemented  on  one  or  more  types  of  multiplexed  data  links  for  which  the  protocols  will  have  to  be 
established.  A  traditional  problem  areas  for  systems  has  been  associated  with  interfaces  and  the 
definition  of  the  signals  on  the  interfaces.  Multiplexed  digital  data  systems  have  increased  the 
problem  except  where  a  single  authority  has  control  of  the  specification. 
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The  only  way  to  manage  and  resolve  such  system-wide  issues  in  the  design  of  an  Integrated  Platform 
Management  System  will  be  to  designate  a  System  Design  Authority.  This  is  a  significant  and  in  the 
UK  a  new  and  challenging  role  in  Platform  System  procurement. 
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VOICE  COMMAND  INVESTIGATION  FOR 
CONTROL  OF  MODERN  CANADIAN  WARSHIPS 

by  Lieutenant (N)  K.R.  Isnor  BEng  MEng 
and  Lieutenant (N)  G.S.  Brown  BEng 
Department  of  National  Defence,  Canada 


1.  ABSTRACT 

The  potential  use  of  speech  recognition  technology  in  the 
control  and  monitoring  of  computer  controlled  systems  is  receiving 
increased  attention.  The  Department  of  National  Defence  of  Canada 
contracted  CAE  Electronics  to  develop  and  test  a  speech  recognition 
system  to  control^  the  SHINMACS*  Advanced  Development  Model  (ADM) . 
The  SHINMACS  ADM  is  a  distributed  microcomputer  based  ship  control 
system  connected  to  a  real-time  computer  simulation  of  a  DDH-280 
class  destroyer.  Because  it  combines  the  flexibility  and 
reliability  of  digital  computers  with  the  simplicity  and  ergonomics 
of  graphic  displays,  it  provides  a  unique  test  environment  for  the 
investigation  of  an  advanced  concept  in  the  control  of  a  modern 
warship. 

After  a  brief  introduction  on  the  theory  behind  speech 
recognition  technology,  this  paper  describes  the  methodology 
followed  to  develop  a  Voice  Command  system  for  SHINMACS  ADM,  and 
it  presents  the  results  of  the  investigation.  The  overall 
requirements  for  the  Voice  Command  system  for  SHINMACS  ADM  are 
described  together  with  the  criteria  used  in  the  selection  of  the 
Speech  Recognizer  units.  The  system  architecture  is  presented 
together  with  hardware  and  software  block  diagrams  to  assist  in  the 
description  of  the  overall  principle  of  operation. 

The  paper  concludes  with  an  identification  of  the  issues  which 
must  be  addressed  and  the  investigation  to  be  performed  before 
actual  implementation  of  Voice  Command  onboard  operational  ships. 

2 .  INTRODUCTION 

In  November  1987  the  Department  of  National  Defence  (DND)  of 
Canada  commissioned  a  study  by  CAE  Electronics  Ltd  of  Montreal  to 


*  .'SHINMACS;  Shipboard  Integrated  Machinery  Control  System 
(Registered  Trademark  of  the  Department  of 
National  Defence) 
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investigate  voice  recognition  technology  for  machinery  control. 
This  study  was  to  investigate  the  feasibility  of  voice  coninand  in 
conjunction  with  the  Integrated  Machinery  Control  System  (IMCS)  as 
fitted  in  the  Canadian  Patrol  Frigates  (CPF)  and  the  Tribal  Update 
and  Modernization  Program  (TRUMP)  ships.  This  project  was 
consistent  with  DND's  desire  to  continuously  improve  the  Man 
Machinery  Interface  (MMI)  of  the  IMCS. 

The  perceived  benefit  of  voice  control  is  improved  operator 
performance  in  a  busy  environment.  An  example  illustrating  the 
potential  benefits  of  Voice  Command  is  the  requirement  to  open  the 
starboard  boost  pump  suction  valve.  Using  the  MMI's  on  the  IMCS 
the  operator  would: 

bring  up  fuel  service  screen  (  one  button  push) 

move  cursor  to  "control  point"  (trackball  manipulation) 

enable  cursor  selection  (one  button  push) 

-  select  desired  option  -  open  valve  (one  button  push) 

Visual  feedback  is  an  on-screen  graphic  representation  of  the  valve 
being  opened. 

Using  a  voice  command  the  operator  would; 

-  issue  a  voice  command  "open  the  starboard  boost  pump 
suction  valve" 

The  visual  feedback  would  be  the  same  as  above. 

It  is  expected  that  operator  performance  under  duress  could 
be  improved  by  replacing  multiple  manual  actions  at  the  MMI  with 
voice  commands. 

3.  SPEECH  RECOGNITION  CONCEPTS 

There  are  four  basic  categories  of  speech  recognition  system 
from  the  "user"  perspective.  A  speech  recognition  system  can  be 
either  speaker  dependent  or  speaker  independent.  If  a  system  is 
speaker  dependent,  then  it  requires  a  sample  of  the  user's  voice 
to  be  stored.  Speaker  independent  systems  contain  algorithms 
designed  to  handle  differences  in  the  human  voice,  such  as  accents 
and  voice  pitches. 

Another  way  of  grouping  speech  recognition  systems  is  by 
determining  whether  they  recognize  either  discrete  isolated  words 
or  continuous  connected  speech.  In  discrete  systems  a  number  of 
sound  patterns,  such  a  distinct  words  or  short  phrases  are  stored 
in  the  recognition  system.  The  user  must  pause  at  the  end  of  each 
word  so  that  the  recognizer  knows  to  search  its  database.  The 
connected  speech  system  requires  no  pause  after  each  word  or 


phrase.  A  recognition  algorithm  is  used  to  decipher  where  each 
word  or  phrase  ends.  Discrete  and  connected  systems  can  be  either 
speaker  dependent  or  independent. 

Figure  1  illustrates  a  typical  process  used  by  voice 
recognition  units  to  "recognize"  a  spoken  command.  It  would  be 
naive  to  suggest  that  these  four  categories  are  the  only  aspects 
of  speech  recognition.  Other  techniques  such  as  the  distinction 
between  phoneme  based  and  whole  word  template  matching,  statistical 
modelling  of  sets  of  templates,  signal  transformation  operations, 
dynamic  time  warping  and  so  on  are  beyond  the  scope  of  this  paper 
and  the  authors'  expertise. 

Successful  implementation  of  a  speech  recognition  system  must 
take  a  number  of  factors  and  constraints  into  account.  Speaker 
related  factors  are  very  important.  Dialects  and  speech 
variability  may  significantly  affect  the  performance  of  speaker 
Independent  systems.  Speech  variability,  or  the  consistency  that 
individuals  replicate  words,  adversely  affects  the  recognizer. 
Background  noise  often  affects  the  speakers  consistency. 

Background  noise  can  also  affect  speech  transmission 

characteristics,  by  degrading  the  signal  and  thus  may  cause 
substitution  errors. 

The  design  of  the  vocabulary  is  an  important  consideration  in 
the  successful  implementation  of  a  speech  recognition  system.  To 
minimize  errors  the  vocabulary  should  be  limited  in  size  and 
distinct.  Enrolment,  or  the  process  of  creating  and  storing  speech 
templates  for  matching  is  very  important.  The  speaker  must  act 
natural  and  enrol  in  the  representative  environment.  A  good 
enrolment  process  will  pay  dividends  later  in  system  use  by 
increasing  the  recognition  percentage. 

4.  SYSTEM  DESIGN  REQUIREMENTS  AND  CONSTRAINTS 

4.1  System  Constraints 

The  major  constraints  placed  by  DND  on  the  contractor  in  the 
design  of  the  system  were: 

a.  the  system  had  to  interface  with  the  existing  SHINMACS 
ADM  without  any  hardware  or  software  modifications.  This 
meant  that  the  voice  system  had  to  simulate  the  input 
functions  of  the  existing  keypad  and  trackball,  and 

b.  the  speech  recognition  units  had  to  be  commercially 
available. 
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Figure  1  ;  Acoustic  Pattern  Matching  Algorithm 
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4.2 


Speech  Recognition  Requirements 


The  preliminary  requirements  established  in  order  to  conduct 
an  evaluation  of  the  various  available  speech  recognition  units 
were  that  the  system  had  to  be  able  to: 

a.  operate  with  a  vocabulary  size  of  approximately  160-200 
words.  This  was  based  on  the  current  page  and  line  menus 
of  the  MMI, 

b.  perform  in  a  high  noise  environment.  This  variable  is 
difficult  to  measure  since  there  are  no  applicable 
standards.  Therefore,  this  requirement  was  judged  on 
previous  applications  of  the  various  speech  recognition 
units  in  comparable  environments, 

c.  operate  via  a  standard  RS-232C  serial  interface, 

d.  allow  expansion  in  both  hardware  and  software,  and 

e.  permit  MMI  operations  to  occur  without  undue  delay.  In 
practice,  recognition  times  are  about  the  same  for  most 
commercial  systems,  ranging  from  200  to  300  milliseconds. 

5.  HARDWARE  SELECTION 

5.1  Speech  Recognizer  Selection 

The  above  requirements  and  others  were  used  to  establish  the 
selection  criteria  for  an  evaluation  of  the  available  recognition 
units.  Two  recognition  units  were  selected  to  be  used  in  the 
evaluation  were  the  Marconi  Macrospeak  and  the  Scott  Instruments' 
Coretechs  VET  3 .  The  Marconi  Macrospeak  was  selected  as  the 
preferred  system  due  to  its  fast  response  time,  expansion 
capabilities,  vocabulary  size,  success  in  similar  applications,  and 
complete  development  tools  package.  The  Macrospeak  was  the  most 
expensive  product.  All  of  the  basic  system  requirements  were 
satisfied.  The  Scott  Instruments’  Coretechs  VET  3  was  selected  as 
the  other  recognition  unit  to  provide  comparison.  The  Scott  system 
was  the  least  expensive  unit  that  met  the  basic  system 
requirements. 

5.2  Computer  Selection 

Several  manufacturers  produce  microprocessors  that  appeared 
capable  of  performing  the  VCC  (Voice  Command  Controller)  functions. 
The  estimate  of  necessary  coi.puter  power  was  envisioned  to  be 
somewhere  between  an  IBM  PC/AT  and  a  DEC  Microvax  II.  Since  the 
voice  recognition  systems  were  anticipated  to  have  a  throughput 
delay  of  approximately  300  milliseconds,  computer  speed  was  an 
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important  function,  although  not  the  only  priority.  The 
requirement  was  to  maintain  a  total  throughput  delay  from  the 
speech  recognizer  to  the  MMI  of  1  second. 

The  identified  computers  were  the  IBM  PS/80,  the  Microvax  2000 
and  the  Macintosh  II.  All  three  processors  had  similar  execution 
speeds,  but  the  IBM  PS/80  was  eliminated  because  it  ran  under  a  new 
operating  system  which  was  not  available  at  that  time.  The  system 
selected  was  the  Macintosh  II.  The  major  advantages  of  the 
Macintosh  II  over  the  Microvax  2000  were  the  user  interface,  the 
expansion  capability,  and  the  cost.  System  software  was  to  be 
developed  under  A/UX  (Apple  Unix) .  The  Unix  development  system 
provided  the  most  flexibility.  By  using  Unix  access  was  gained  to 
powerful  tools  and  compilers. 

6.  SYSTEM  OVERVIEW 

6.1  Hardware  Configuration 

The  overall  hardware  configuration  is  presented  in  figure  2. 
The  system  consists  of  a  speech  recognition  unit  interfaced  to  a 
VCC  software  package  running  on  a  Macintosh  li  computer.  The 
Macintosh  II  is  connected  to  the  SHINMACS  ADM  via  the 
record/playback  RS-232  port  of  the  Datapath  M  General  Purpose 
Interface  (MGPI)  in  the  MMI  console. 

6.2  Software  Configuration 

The  operation  of  the  MMI  console  using  verbal  commands  is 
illustrated  in  figure  3.  This  voice  command  set  up  typically 
operates  in  the  following  manner  [1]: 

a.  Incoming  Data  Handler.  This  module  is  custom  tailored 
to  the  voice  recognizer  being  used.  Its  task  is  to  accept  output 
from  the  voice  recognizer,  covert  this  data  into  a  Standard  Data 
Packet  (SDP) ,  and  transmit  this  data  to  the  Voice  Interpreter  task. 
This  data  packet  contains  information  such  as  flags  for  connected- 
isolated  words  and  speaker  dependent-independent  modes. 

b.  Voice  Interpreter  Task.  This  module  receives  the  SDP  of 
information  from  the  incoming  data  handler  and  provides  a 
corresponding  command.  This  task  outputs  commands,  which  are 
simple  Integers  that  can  be  used  to  look-up  in  a  master  table. 
This  module  has  different  run  states  set  by  arguments  passed  to  the 
executable  program  so  that  the  voice  system  can  run  in  an  isolated 
or  connected  mode. 

In  isolated  word  mode  the  voice  recognizer  (Scott  VET  3) 
chooses  the  target  word  (command)  and  passes  along  a  corresponding 
reference  number  for  future  use. 
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Figure  2  :  Hardware  Configuratioa  |1] 


Figure  3  :  Software  Configuratioa  lU 


In  the  connected  speech  recognition  mode  (Marconi 
incoming  data  packets  are  received  on  a  per  word  basis  "ob  on  a  per 
command^  basis  as  with  isolated  recognition.  This 
buffer  incoming  candidate  words  until  enough  words  ®f®  ^®^®^ 
complete  a  co^and.  When  this  occurs  the  appropriate  co^^nd 
refLence  number  is  sent  out,  buffers  are  reset  and  the  command 
building  task  continues. 

c.  command  Look  Up.  This  module  is  based  on  a  data  driven 
look  up  procedure.  Using  the  command  received  from  bhe  Voice 
Interpreter  module,  this  module  finds  the  appropriate  commands  to 
be  seSt  to  the  device  being  controlled.  In  the  P^®®®*'^  ^PP^^^^gg®" 
this  module  maps  input  commands  to  escape  sequences  that  are  sent 
to  the  MMI  console. 

d.  Machine  Control.  The  final  module  transmits  the  escape 
sequence  from  the  Command  Look  Up  module  to  the  machine  being 
co^rolled.  The  design  of  this  task  will  depend  upon  what  the 
target  machine  expects  for  a  communication  protocol. 


7 .  EVALUATIOM 

The  evaluation  of  the  voice  recognition  units  was  conducted 
at  CAE  Electronics  in  Montreal,  March  13-15  1989.  ®valuation 

team  consisted  of  eight  persons,  four  from  CAE 
personnel  (two  Marine  Systems  Officers,  one  Marine  Engineering 
Technician  and  one  Marine  Electrician) . 

The  evaluation  scenario  contained  standard  operatior^  and 
typical  alarms  and  warning  conditions  that  an  operator  must  handle 
in  the  routine  operation  of  the  IMCS.  This  included  the  operation 
of  auxiliary  and  ancillary  systems,  and  the  starting,  operation  and 
shutdown  of  main  engines.  The  scenario  was  designed  to  test  normal 
start-up  and  shutdown  procedures,  system  operations  during  engine 
trips,  and  alarm  conditions  with  machinery  component  failures.  The 
commands  to  the  recognizer  were  also  mixed  with  communications  to 
and  from  the  Engineering  Officer  of  the  Watch  (EOOW) . 


For  this  evaluation,  both  speech  recognition  systems,  the 
Marconi  Macrospeak  and  Scott  Instruments  Coretechs  VET3  were 
interfaced  with  one  of  the  SHINMACS  ADM  MMIs.  Since  both  systems 
are  speaker  dependant,  each  member  of  the  evaluation  team  had  to 
"train"  the  recognizer  to  recognize  his/her  voice  by  storing  a 
representation  of  his/her  voice  called  a  template.  Since  the 
Macrospeak  is  a  continuous  recognizer,  only  the  individual  words 
involved  in  a  command  need  be  stored  as  templates.  The  VET3  was 
used  in  an  isolated  mode.  This  meant  that  every  possible  command 
phrase  had  to  be  enroled  and  stored  as  a  template.  This  was  time 
consuming . 


A  three  day  evaluation  was  planned.  The  first  day  was  to 
begin  with  a  familiarization  of  the  console  operation  and  the  test 
scenario.  Then  template  training  for  both  recognizers  was  to  take 
place.  The  second  day  was  allocated  to  practising  the  test 
scenario  with  both  speech  recognizers  and  retraining  the  templates 
as  required.  The  final  day  was  to  be  dedicated  to  the  actual 
evaluation.  The  CAE  personnel  followed  the  three  day  evaluation 
program.  Unfortunately  during  the  DND  evaluation  there  was  a 
province  wide  power  blackout  forcing  the  three  day  evaluation  to 
be  compressed  into  two  days.  To  accommodate  this  the  number  of 
template  training  passes  for  the  VET3  was  reduced  from  ten  to  five. 
This  affected  the  accuracy  of  the  VET3  recognizer. 

8.  EVAUIATION  RESULTS 

The  results  from  the  evaluation  are  presented  as  a  number  of 
correct  and  incorrect  responses  by  the  recognizer  to  an  operator 
command.  A  correct  response  by  the  recognizer  constitutes  properly 
identifying  the  spoken  verbal  command  or  rejecting  an  invalid 
verbal  command.  Likewise  incorrect  responses  include  improperly 
identified  verbal  commands,  not  rejected  invalid  commands,  operator 
error  and  poor  templates.  The  measure  of  performance  for  the 
Macrospeak  and  VET3  speech  recognizers  was  the  number  of  correct 
responses  over  the  total  number  of  correct  and  incorrect  responses 
and  then  averaged  over  the  whole  evaluation  team.  Overall 
performances  of  92.4%  correct  for  the  Macrospeak  and  80.2%  correct 
for  the  VET3  were  found.  These  figures  corrected  for  operator 
error  and  poor  templates,  were  94.9%  and  86.5%.  A  comparison  of 
the  results  for  the  CAE  and  the  DND  personnel  revealed  that  the 
results  were  almost  identical.  Recognition  accuracy  for  the 
Macrospeak  was  96.7%  for  the  CAE  personnel  and  93.3%  for  the  DND 
personnel.  Likewise  the  accuracy  for  the  VET3  was  86.4%  for  the 
CAE  personnel  and  86.5%  for  the  DND  personnel. 

Compounding  the  difference  between  the  Macrospeak  and  the  VET3 
was  the  fact  that  the  Macrospeak  was  working  in  a  connected  mode 
and  approximately  four  templates  must  be  recognized  for  each 
command,  while  the  VET3  was  working  in  the  isolated  mode  and  each 
template  was  a  complete  command. 

The  Macrospeak  and  VET3  voice  recognizers  both  met  all  the 
requirements  and  constraints  established  for  this  project.  Noting 
these  constraints,  limitations  and  subjective  nature  of  this 
project,  the  connected  speech  recognition  mode  implemented  in  the 
Marconi  Macrospeak  appears  to  be  more  suitable.  User  acceptance 
of  voice  command  by  the  evaluation  team  was  generally  good  for  the 
Macrospeak  and  fair  for  the  VET3.  The  evaluation  team  also 
Indicated  that  the  preferred  mode  of  operation  of  the  MMl  would  be 
a  combination  of  voice  and  manual  inputs  to  the  MMI. 
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9. 


COMCUISIONS 


Based  on  the  evaluation  results,  the  feasibility  of  using 
voice  as  an  alternative  input  medium  in  the  control  and  monitoring 
of  computer  controlled  systems  was  successfully  demonstrated.  As 
an  input  medium  for  the  control  of  machinery  systems  the  system  was 
well  received  by  the  evaluation  personnel  with  few  problems 
encountered . 

The  evaluation  determined  that  speech  recognition  as  an  input 
medium,  rather  then  manual  input,  has  the  following  advantages  : 

a.  direct  access  to  any  page  without  the  need  for  the  menu 
hierarchy ; 

b.  less  time  required  by  the  operator  to  perform  each  tas^; 

c.  potential  for  the  use  of  macro  commands;  and 

d.  the  system  is  language  independent  (i.e.  English,  French, 
etc)  . 

However,  several  problems  were  encountered  with  the  system. 
Substitution  errors,  where  an  erroneous  command  was  substituted  for 
the  intended  action,  were  noted  as  the  most  critical.  Background 
conversations,  being  picked  up  and  acted  upon  as  commands,  was 
another  area  that  created  problems.  However,  the  majority  of  the 
difficulties  dealt  with  concepts  involved  in  the  definition  of  a 
man-machine  interface  (MMI) . 

10.  POTORE  DEVEIiOFMEHTS 

Future  developments  in  voice  command  of  HMI's  for  Navy  ships 
would  incorporate  additional  system  logic  into  the  voice 
recognition  units  to  reduce  the  possibility  of  error.  An  example 
of  this  would  be  the  voice  command  "stop  the  number  one  diesel". 
If  the  number  one  diesel  was  the  only  diesel  running  and  provided 
the  recognizer  detected  the  words  "stop"  and  "diesel"  then  the 
system  would  stop  the  only  running  diesel  on  the  screen.  Other 
logical  areas  of  investigation  would  be  the  incorporation  of  the 
"abort"  and  "undo"  commands.  Macros  that  define  a  series  of 
commands  can  also  be  investigated.  Examples  of  this  are  "shut  down 
the  plant". 

Perhaps  the  roost  important  area  of  investigation  would  be 
incorporating  the  design  of  voice  command  right  into  a  machinery 
control  system.  The  investigation  detailed  in  this  paper  used  a 
voice  recognizer  that  simply  replaces  a  trackball  or  keypad.  This 
is  probably  not  the  most  efficient  method  of  incorporating  voice 
recognition  technology  and  other  methods  must  be  investigated. 
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SHIP  CONTROL  -  THE  HUMAN  FACTORS 
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1.  ABSTRACT 

Ships  have  evolved  from  relatively  simple  systems  where  most  functions  were 
performed  by  hand  to  extremely  complex  ones  where  a  very  small  number  of  people 
are  responsible  for<  and  remote  from,  many  complex  subsystems.  The  resulting 
human  task  in  the  machinery  area  has  many  similarities  to  those  found  in 
command  systems  on  the  same  ships. 

The  evolution  of  MMI  in  RN  command  systems  over  the  last  twenty  years  is 
reviewed  to  draw  lessons  which  should  carry  over  into  modem  ship  control  systems. 

2.  INTRODUCTION 

The  earliest  ships  were  fairly  simple.  Their  capabilities  were  limited,  but 
within  those  limits  they  could  be  operated  effectively  with  a  combination  of  practical 
experience  and  brawn.  As  ships  grew,  the  need  for  brawn  expanded  in  proportion, 
leading  to  a  complex  organisational  structure  whose  purpose  was  to  operate  an 
equally  complex  mechanical  system,  the  ship. 

In  the  pre  industrial  days,  although  the  technology  may  have  been  primitive, 
the  amount  of  distributed  intelligence  in  the  control  system  was  very  high.  Even  the 
most  humble  seaman  could  see  that  a  rope  had  broken  and  realise  that  someone 
ought  to  do  something  about  it.  More  significantly,  he  could  do  this  even  if  his  job 
was  carrying  cannon  balls  and  not  monitoring  rope  condition. 

It  may  be  argued  that  the  seaman  was  a  'labourer'  and  so  his  knowldge  outside 
his  immediate  task  was  shallow.  However,  the  technology  used  was  'visible'  in  the 
sense  that  the  function  of  most  components  could  be  inferred  from  looking  at  them. 
The  crew's  work  brought  them  into  close  contact  with  the  equipment.  They  would 
be  familiar  with  the  sounds  made  by  the  ship  and  its  equipment  and  they  would  be 
aware  that  a  component  about  to  fail  'sounded  wrong'  to  an  extent  which  would 
make  an  expert  system  based  condition  monitoring  equipment  turn  green  with 
envy. 
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The  advent  of  powered  technology  did  several  things.  It  allowed  ships  to 
become  bigger  and  more  complex  in  themselves,  and  in  the  case  of  warships,  it 
allowed  them  to  carry  a  proliferation  of  ever  more  complicated  payloads. 

But  perhaps  the  most  significant  change  was  in  breaking  the  link  between 
brawn  and  brain.  The  need  for  men  was  not  abolished,  since  the  machines  needed 
minding.  They  had  brawn,  but  they  neither  knew  what  to  do  nor  when  to  do  it. 
They  could  not  even  take  orders.  Men  were  used  increasingly  as  control  elements. 
They  combined  the  ability  to  turn  an  order  into  an  action  with  a  degree  of  local 
common  sense.  Compart  with  the  machines,  they  were  'managers’,  even  if  their 
jobs  involved  a  lot  of  humdrum  and  arduous  work. 

As  long  as  the  equipment  needed  minding,  the  density  of  brain  power  around 
the  ship  still  stayed  pretty  high.  The  men  could  become  proficient  in  understanding 
their  part  of  ship  and  how  it  worked.  Continuous  familiarity  ensured  this.  What 
was  much  less  sure  is  that  they  would  know  what  it  ought  to  do.  The  operator's 
view  of  an  equipment  is  very  different  from  its  designer's.  They  can  have  very 
different  ideas  about  what  it  can  and  ought  to  be  able  to  do.  This  has  both  strengths 
and  weaknesses.  It  means  the  operators  will  find  ways  of  overcoming  design 
deficiencies  to  coax  more  out  of  equipment  when  needed,  but  it  may  also  mean  they 
never  try  to  make  it  do  things  they  find  unfamiliar  or  difficult. 

The  other  problem  of  specialisation  and  localised  control  is  that  good  old 
human  problem  of  communication.  More  specialisation  means  more  people  have 
to  trust  others  to  do  what  they  do  not  understand  themselves  in  detail.  There  is 
more  interpretation,  more  transformation  of  information  en  route.  In  short,  more 
chance  that  the  impossible  will  be  asked  and  that  the  inappropriate  will  be  done. 

Following  hard  on  the  heels  of  power  technology,  came  control  engineering. 
This  really  does  have  the  power  to  empty  the  compartments.  The  development  of 
reliable  servo  mechanisms  allows  direct  control  and  monitoring  to  be  replaced  with 
output  demand  and  alarm  thresholding.  The  bandwidth  of  the  human  input 
required  drastically  falls,  and  can  be  centralised.  This  really  does  allow  the 
brainpower  density  around  the  ship  to  be  reduced. 

3.  AUTOMATION 

So  all  the  problems  are  over?  That  was  the  popular  vision  in  the  few 
decades  after  the  war  when  the  potential  of  automatic  control  was  becoming  more 
apparent.  Utopia  seemed  to  be  round  the  corner.  Manual  work  would  be 
poerformed  by  machine,  tedious  chores  would  be  automated  and  the  electronic 
brain'  would  schedule  and  organise  the  whole  process.  Has  it  happened  yet? 
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The  technology  is  certainly  there.  There  is  an  actuator  for  every  need,  there  is 
communications  and  processor  bandwidth  in  abudance.  We  can  construct  control 
systems  of  undescribable  complexity.  But  it  is  here  that  we  meet  the  limitation.  A 
control  system  will  only  do  what  we  want,  if  its  designers  can  wrestle  with  the 
complexity  of  specifying  and  testing  it.  A  monitoring  system  is  only  as  good  as  the 
sense  that  its  op)erators  can  make  of  what  it  tells  them. 

These  dual  problems  of  specifying  what  the  system  ought  to  do  and 
understanding  what  it  has  done  provide  one  of  the  biggest  challenges  of  system 
design.  The  problem  is  by  no  means  limited  to  ship  control  or  even  to  process 
control.  They  have  parallels  in  military  and  civil  command  systems  and  in  many 
other  information  systems.  In  fact,  information  is  the  key  issue.  Having  solved  the 
brawn  problem,  we  are  now  faced  with  the  brain  problem.  How  can  we  heap  the 
control  of  far  more  complex  systems  onto  a  far  smaller  number  of  brains,  especially 
since  we  usually  expect  them  to  do  everything  in  much  quicker  timescales. 

4.  INFORMATION 

Information  is  slippery  stuff.  Shannon's  theory  allows  us  to  quantify  the 
information  content  of  a  signal  quite  precisely  in  terms  of  the  number  of  possible 
signals  which  could  be  sent  along  a  communication  channel.  This  is  very  useful  for 
ensuring  that  the  interfaces  between  different  parts  of  a  system  do  not  become  bottle 
necks  for  data  transmission,  but  is  less  helpful  for  real  information'. 

For  example,  faithful  transmission  of  speech  requires  64kbits/second,  viewed 
as  an  accoustic  signal.  Statistical  analysis  and  predictive  algorithms  can  reduce  this  to 
a  few  thousand  bits/sec.  In  fact  the  message  can  be  transmitted  with  a  few  tens  of 
bits  per  second,  if  we  first  translate  it  into  English  and  then  send  coded  text.  The 
information  changes  when  we  'know  what  it  means'.  To  the  transmission  channel 
there  is  less  information  while  to  the  listener,  there  is  more  information,  since  it 
does  not  mean  anything  until  he  has  understood  it.  This  subtle  difference  is  crucial 
to  understanding  the  way  people  work  with  machines  and  designing  machines  they 
can  use  effectively. 

The  men  in  a  ship  rely  on  the  inaeasingly  complex  collection  of  machines 
which  it  contains  to  help  them  achieve  a  mission,  but  their  ability  to  do  so  depends 
critically  on  whether  they  can  understand  and  take  decisions  based  on  the  wealth  of 
data  which  the  machines  can  handle.  This  means  the  interface  between  the  men 
and  the  machines  must  be  designed  for  human  capabilities  and  human  needs.  As  in 
most  areas  of  human  endeavour,  progress  comes  in  fits  and  starts  with  occasional 
reversals.  Paradoxically  it  is  not  easy  to  design  effective  user  interfaces,  especially 
when  technological  motivators  take  over.  We  shall  look  at  the  progress  made 
during  the  era  of  rapid  system  evolution  enabled  by  the  advent  of  onboard 
computers. 
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5.  KNOBS  AND  DIALS 


Ships  and  submarines  have  been  around  for  far  longer  than  terms  like  MMl 
and  its  many  synonyms  have.  They  were  full  of  machines  and  they  were  operated  by 
men,  but  no  one  thought  to  identify  the  interface  between  the  two  as  such.  At  the 
basic  level  equipment  was  designed  to  be  used.  Most  equipment  needed  controls  of 
various  forms  but  these  related  quite  closely  to  what  was  being  controlled,  often  in  a 
one  to  one  relationship  with  each  variable. 

At  this  level  there  can  be  good  intuitive  grasp  of  the  underlying  process.  A 
flow  is  controlled  by  a  valve,  a  valve  is  screwed  down  by  a  wheel,  and  the  pressure  in 
the  pipe  is  read  out  by  a  gauge.  Gauge  designers  take  pride  in  producing  clear 
readable  instruments  and  valve  wheels  are  designed  to  be  gripped  so  that  force  can  be 
applied.  (There  are,  of  course  exceptions). 

This  cosy  picture  breaks  down  because  it  takes  rather  a  lot  of  valves  to  operate  a 
submarine,  and  success  depends  on  opening  and  closing  the  right  ones  by  the  right 
amounts  at  the  right  times.  So  we  impose  higher  level  models  to  help  us 
understand  the  relationships  between  them.  Flooding  aft  or  forward  tanks  makes 
the  boat  bow  or  stem  heavy  and  causes  a  corresponding  pitching  moment.  We  can 
build  controls  and  indicators  into  'pictures'  such  as  deck  plans,  piping  or  wiring 
diagrams  to  help  understand  them.  Such  mimic  diagram  style  control  panels  can  be 
very  successful,  but  as  they  get  bigger  we  can't  show  both  the  overall  scope  and  the 
full  detail,  especially  if  the  system  model  does  not  neatly  map  onto  a  2-D 
representation.  This  is  a  much  more  general  problem,  as  we  shall  see. 

6.  VALUES,  SYMBOLS,  AND  IMAGES 

A  submarine  may  swim  and  breathe  supported  by  machines  which  are 
essentially  analogue.  They  deal  with  real  physical  values  like  speed,  pressure  voltage 
and  so  on.  But  the  submarine's  mission  is  made  of  more  rarefi^  stuff.  It  is  a  tactical 
machine,  and  tactics  hinge  on  information,  lots  of  it.  Intelligence  about  intentions 
and  possibilities,  copious  output  of  sensors  and  masses  of  reference  information 
about  everything  from  the  environment  to  tactics.  Whilst  many  of  the  data  in  this 
mass  of  information  do  in  fact  relate  to  physical  variables,  many  do  not.  Tactical 
information  is  primarily  symbolic.  It  is  information  with  a  capital  T. 

Another  useful  broad  category  of  information,  very  pertinent  to  a  submarine, 
we  may  loosely  call  'images'.  Images  can  be  thought  of  as  masses  of  value,  whose 
overall  pattern  is  important  but  where  individual  values  are  relatively  unimportant, 
and  indeed  may  be  quite  'noisy'.  This  is  in  stark  contrast  to  symbolic  information 
where  individual  errors  can  significantly  alter  meaning. 
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COMPLEXITY 


Complexity  is  the  enemy  and  the  challenge  of  human  information  systems. 
People  over  load  under  pressure  of  excessive  information.  This  simple  fact,  well 
known  to  psychologists,  is  masked  by  two  remarkable  human  mechanisms.  The 
human  mind  has  an  appetite  for  pattern  and  order.  (Pure  scientific  endeavour,  for 
instance,  is  driven  by  the  urge  to  find  order  and  predictability  in  the  physical  world). 
By  extracting  pattern  and  order  from  information,  by  'seeing  what  it  means',  we  are 
able  to  handle  far  larger  amounts  than  we  could  otherwise. 

The  other  mechanism  is  more  severe.  Overloaded  brains  simply  shed  load.  In 
the  case  of  perceptual  overload,  we  just  fail  to  see  or  hear  things.  Unfortunately  we 
often  do  not  know  what  we  failed  to  see,  -  until  it  becomes  too  late. 

The  battle  against  complexity  can  only  be  won  by  abstracting  from  the  detail  to 
the  underlying  essence  or  structure  of  the  concepts  which  allow  people  to  organise 
the  information  and  make  it  manageable. 

8.  EVOLUTION  OF  COMMAND  SYSTEMS 

8.1  Technology  Drivers 

Each  age  of  history  has  been  driven  by  different  concerns.  Similarly,  with  the 
application  of  a  new  tedtnology,  there  is  a  natural  progression  from  'can  it  be  done', 
through  'can  it  be  done  better,  more  efficiently,  more  cheaply',  'how  should  it  be 
done',  to  'what  should  we  actually  be  doing'.  This  is  as  true  of  technology  in 
submarines  as  it  is  of  technology  in  the  office. 

Introducing  computers  into  fighting  vessels  was  a  challenge.  Making  them 
small  enough  and  feeding  them  with  high  grade  power  was  an  achievement.  The 
tasks  they  were  asked  to  perform  were  more  demanding  than  those  being  performed 
by  many  civilian  computers  at  the  time.  By  supporting  real  time  information  display 
and  management,  they  were  at  the  forefront  of  MMI  technology. 

Early  shipboard  computer  systems  pressed  into  service  and  adapted  the  MMI 
technology  that  was  available.  Radar  systems  had  already  perfected  large  CRT 
displays  capable  of  high  speed  precision  X-Y  scanning.  The  computer  manufacturers 
rose  to  the  challenge  and  developed  sophisticated  display  drivers  to  allow  large 
quantities  of  symbolic  information  to  be  written  on  the  displays. 

The  parentage  of  these  systems  is  apparent  at  a  glance;  they  are  circular.  With 
an  electrical  generator  capable  of  producing  a  square  picture  and  a  square  area  of  the 
valuable  console  space  in  front  of  the  user  available,  we  would  not  otherwise  have 
specified  circular  screens,  and  then  often  only  written  information  in  a  square  area 
inscribed  within  the  circle. 
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Television  already  used  rectangular  CRTs,  but  it  took  a  while  for  the  glassware 
to  find  its  way  into  high  performance  military  displays.  TV  display  technology  itself 
was  in  a  much  lower  league.  We  could  not  seriously  contemplate  TV  style  raster 
technology  for  high  density  information  displays  until  digital  storage  had  become 
much  faster  and  cheaper.  In  the  early  '70s,  core  storage  would  have  been  too  slow, 
and  at  around  4p  per  bit  would  have  cost  several  hundred  thousand  pounds,  (more 
than  the  cost  of  the  computer  systems  of  the  day),  to  support  one  screen  of  what  is 
now  a  standard  technical  workstation,  commercially  available,  for  under  ten 
thousand  pounds,  with  its  own  built  in  computer. 

Two  decades  ago,  military  display  systems  led  the  field.  Only  very  high  value 
civilian  tasks  were  supported  by  sudi  technology.  Now  the  high  grade  raster  display 
has  came  into  its  own  thanks  to  the  phenomenal  advances  in  cheap  semiconductor 
store.  Raster  displays  are  more  energy  efficient  than  cursive  ones,  and  more 
amenably  offer  multi-colour  pictures.  They  allow  the  generation  of  the  picture  to  be 
divorced  from  its  refresh,  (the  main  headache  of  cursive  displays).  This  means  a 
screen-full  can  be  displayed  as  easily  as  a  few  symbols,  but  at  the  cost  of  storing  the 
screen  image  in  a  bit-thirsty  way. 

As  memory  prices  tumbled,  more  and  more  commercial  jobs  could  afford  not 
only  to  use  computers,  but  also  to  use  high  performance  displays.  The  initiative 
passed  from  the  military  to  the  civilian  developers.  The  IT  market  poured  in  the 
dollars  and  the  yen  while  military  buyers  concentrated  more  on  frying  to  get  systems 
into  service  rather  than  expecting  to  fund  the  advance  of  technology.  Increasingly, 
military  hardware  became  a  hardened  derivative  of  technology  originally  forced  into 
being  by  commercial  pressures. 

8.2  Early  Days  in  Command  Information  System  MMI 

In  a  sense,  the  User  Interface  is  the  raison  d'etre  of  a  command  information 
system,  so  it  was  no  surprise  that  the  'automation'  of  many  jobs  previously  relying 
on  charts  and  chinagraph  in  the  '60s  raised  many  MMI  problems. 

Early  computers  were  too  large  to  be  carried  on  submarines  and  so  it  fell  to  the 
surface  fleet  to  suffer  the  early  part  of  the  learning  curve.  Display  capability  was 
severely  limited,  despite  exploiting  the  persistence  of  fluoride  phosphors  to  run  the 
tubes  at  very  low  refresh  rates.  But  some  of  the  worst  surprises  came  on  the  input 
side.  Using  keyboards  seemed  appropriate,  but  no  one  can  have  foreseen  the 
problems  of  managing  a  real  time  system  using  memorised  sequences  of  cryptic 
codes.  It  may  all  seem  very  logical  when  you  are  inventing  them,  but  use  in  anger, 
under  pressure,  is  a  different  matter. 
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Using  codes  could  have  been  less  painful  as  part  of  a  more  forgiving  dialogue, 
but  such  was  the  respect  for  computers  in  those  days  that  users  were  assumed  not  to 
make  mistakes,  or  if  they  did,  then  it  was  not  the  system  designers  problem. 

8.3  Pioneering 

As  in  so  many  areas,  it  is  best  to  be  second.  When  DCA  was  introduced  into 
submarines,  technology  had  moved  on  somewhat,  as  had  ideas  about  user  interfaces. 
Using  a  light  pen  enabled  the  selection  of  individual  items  displayed  on  the  screen 
with  a  reasonably  natural  action.  This  made  possible  a  'conversational  mode'  of 
interaction  with  the  system.  At  any  one  time,  the  system  shows  what  it  can  respond 
to  and  control  consists  of  selecting  one  or  more  of  these  options.  The  changing 
presented  options  reflect  the  dynamics  of  the  interaction. 

This  style  of  interaction  was  a  major  advance  over  the  use  of  key  codes.  It  was 
more  learnable,  and  less  error  prone.  It  was  in  advance  of  most  commercial  systems 
of  the  day.  The  surface  fleet  had  this  style  of  MMI  on  the  WSA4  weapon  control 
system,  but  had  to  wait  another  decade  until  CACS  brought  the  ideas  to  the  main 
stream  Action  Information  systems. 

While  the  command  systems  were  going  to  sea,  the  research  establishments 
were  pushing  back  the  barriers  for  the  sonar  operator.  As  the  sonar  systems  were 
developing  to  generate  ever  more  complex  sets  of  'image  data'  a  better  means  was 
needed  to  display  it  for  interpretation.  Although  raster  technology  in  its  present 
form  was  not  yet  mature,  pioneering  work  with  displays  refreshed  direct  from 
magnetic  disc  allowed  considerable  progress  from  a  choice  between  paper  readouts 
and  fading  images  on  fluoride  phophors. 

DCA  opened  Pandora's  box  by  showing  what  could  be  done.  Unfortunately, 
neither  it  nor  its  successors  could  keep  up  with  the  demands  placed  on  them.  This 
led,  among  other  things,  to  the  need  for  add-ons  like  DCG,  and  a  consequent 
complication  of  the  user  interface  to  the  total  enhanced  system  suite. 

DCG,  born  out  of  Corporate,  is  a  good  example  of  accepting  the  constraints  of 
using  commercial  technology.  The  MMI  also  reflects  what  was  commercially 
acceptable  at  the  time,  and  although  the  system  as  a  whole  gave  a  much  needed 
functional  upgrade  to  DCB,  the  MMI  itself  was  less  advanced  than  DCB  in  using 
indirect  selection  by  keyboard  with  a  constrained  menu  format. 
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8.4  The  Present 


The  move  from  DCB/DCG  to  SMCS  will  represent  a  major  step  on  many 
fronts.  The  display  capacity  per  seat  exceeds  DCB  and  DCG,  and  for  the  first  time 
offers  colour.  The  greatly  increased  underlying  processing  power,  although  it  is  not 
superficially  an  MMI  feature,  will  change  the  way  the  system  is  used  by  providing 
results  after  delays  small  enough  to  be  tolerated,  whereas  long  delays  encourage 
distortion  of  the  task  to  work  round  them. 

SMCS  retains  the  concept  of  control  by  selection  from  a  dynamic  set  of 
displayed  features,  though  the  structure  and  organisation  differs  quite  markedly 
from  earlier  systems.  At  the  physical  level,  the  need  for  hands  up  operation  has  been 
replaced  at  the  cost  of  splitting  the  interaction  into  two.  The  main  display,  primarily 
responsible  for  the  tactical  picture,  uses  a  mouse-like  puck  with  pull  down  menus, 
leaving  the  more  detailed  procedural  and  data  oriented  actions  to  a  desk  level  display 
with  a  touch  overlay  doubling  as  a  'glass  key  panel'. 

The  success  of  this  combination  :n  service  will  depend  as  much  on  the  logical 
structure  of  the  detailed  interactions,  and  how  well  they  can  be  made  to  match  the 
inherent  needs  of  the  tasks,  as  it  does  on  the  more  visible  physical  aspects.  SMCS 
represents  such  a  major  departure  from  previous  systems  that  it  would  be  premature 
to  speculate  on  the  cognitive  ergonomic  aspects,  since  the  tasks  themselves  will  be 
changed  by  the  system  provided  to  support  them.  This  joint  evolution  of  the  job  and 
the  tool  could  provide  some  valuable  lessons  for  the  bigger  steps  to  be  taken  in  the 
next  generation. 

SSCS,  the  new  command  system  for  the  Type  23  Frigate,  will  build  on  the  basic 
technology  established  in  SMCS,  but  it  has  made  the  transition  to  an  object  oriented 
style  of  user  interface.  Extensive  use  of  direct  interaction  and  an  adaptive 
windowing  system  provide  the  user  with  a  much  clearer  set  of  views  of  the  resources 
under  his  control.  The  interface  style  is  specifically  designed  to  support  an 
appropriate  conceptual  model  for  the  users. 

Another  major  advance  introduced  for  SSCS  is  a  comprehensive  Human 
Engineering  Plan.  Although  human  factors  have  played  an  accepted  role  in  the 
development  of  aircraft  cockpits  and  primary  instruments  for  many  years,  large 
command  systems  have  traditionally  been  procured  predominantly  as  bundles  of 
functionality.  The  SSCS  development  will  deliver  functionality,  but  the  behaviour 
of  that  functionality  as  it  will  be  experienced  by  its  intended  users  will  be 
systematically  validated  throughout  the  development  cycle. 
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«.S  The  Npxt  Step  in  Command  Systems 

It  is  significant  that  before  SMCS  is  even  at  sea,  the  foundatons  are  being  laid 
for  an  Integrated  Weapon  System  for  the  new  generation  SSN20.  This  is  a  far  sighted 
approach,  Ince  new  concepts  can  not  be  rushed  through  without  time 
The  Mod  needs  time  to  draw  together  the  ideas  which  it  is  stimulating  from  its 
contractors  into  a  coherent  whole  in  line  with  its  high  level  goals. 

The  integrated  approach  from  the  outset  should  help  to  ensure  that  all  sub¬ 
systems  properly  communicate  with  each  other.  Using  people  to  pass  information 
from  one  piece  of  kit  to  another  merely  raises  the  noise  level,  both  literally  and 
metaphorically,  by  distracting  the  users  from  its  meaning  and  use. 

The  inherent  recognition  in  SSN20  of  the  human  team  as  a  'people  subsystem' 
inseparable  from  the  whole  system  design  process  is  undoubtedly  an  important  step 
ahead.  If  Weapon  System  Integration  on  the  scale  envisaged  is  to  succeed,  in  an  era 
of  reducing  complements,  the  human  issues  of  what  the  system  is  about  must  be 
given  equal  prominence  to  the  more  obvious  technological  ones. 

9.  FUTURE  ISSUES  FOR  COMMAND  SYSTEMS 


The  future  will  be  different,  but  we  should  try  not  to  repeat  past  mistake^ 
Some  things  will  remain  invariant,  such  as  men's  size,  vision,  response  speed  and 
cognitive  abilities.  Reduced  complements  may  allow  for  less  cramped  working 
spaces,  but  equipment  will  still  have  to  pass  through  hatches. 

We  noted  that  as  a  technology  matures,  the  focus  shifts.  We  can  build  fairly 
good  devices  to  display  information,  and  there  are  well  established  paradigms  to 
support  its  manipulation  and  use.  Though  both  will  continue  to  advance  soinewhat, 
the  real  issues  are  about  how  the  systems  need  to  match  the  way  they  are  used.  More 
and  better  integration  of  sub-systems  should  push  rote  tasks  like  data  entry  and 
coordination  to  the  periphery.  Having  men  there  just  to  drive  the  systems  vs^ile 
others  think  about  the  problem  will  no  longer  be  necessary  and  indeed  will  be  a 
hindrance,  a  barrier  between  the  decisions  maker  and  his  problem.  The  inevitable 
consequence  will  be  a  move  to  men  as  information  managers  rather  than  many 
being  information  servants.  The  resultant  up-skilling  can  provide  more  stimulating 
jobs,  but  only  if  the  career  progression  structures  can  evolve  to  match. 
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As  the  complexity  of  the  resources  available  to  each  user  continue  to  grow,  it 
will  no  longer  be  sufficient  to  provide  a  'sanitary'  interface,  free  of  weak  points. 
Increasingly,  the  whole  edifice  of  the  information  and  its  representation  will  have  to 
be  designed  to  support  the  way  the  problems  need  to  be  solved.  In  particular,  as  the 
machines  provide  increasing  support  to  the  decision  making  processes,  rather  than 
just  the  data  gathering  and  processing  aspects,  they  will  become  more  and  more 
embroiled  in  supporting  the  combat  team  as  a  team  rather  than  as  a  collection  of 
individuals. 

The  navy  has  a  long  tradition  of  developing  procedures  to  allow  teams  of  men 
to  work  effectively  together  under  stress.  This  has  relied  on  a  good  understanding  of 
human  behaviour  and  communication.  In  the  future,  this  perspective  must 
broaden  to  embrace  communication  between  men  mediated  by  machine,  as  well  as 
face  to  face.  They  will  increasingly  share  the  resources  provided  by  the  system  rather 
than  be  constrained  by  a  narrow  set  of  facilities. 

Knowledge  based  technology  will  mature.  It  can  provide  a  richer  set  of 
resources  to  the  men.  But  the  way  of  using  such  resources  will  be  different.  Creating 
machine  'agents'  to  which  tasks  can  be  delegated  or  from  which  suggestions  be 
elicited  will  provide  good  models  for  the  new  dimensions  of  communication 
needed.  The  issues  of  trust,  authority  and  responsibility  for  information  are 
challenging  ones  which  must  be  solved  if  men  are  to  use  the  next  generation  of 
machines  as  effective  tools  to  help  them  achieve  ever  more  demanding  missions. 

10.  LESSONS  FOR  SHIP  CONTROL 

10.1  Similarities 


Command  systems  installed  or  in  the  pipeline  for  RN  ships  and  submarines 
have  come  a  long  way  since  digital  computers  first  went  on  board  in  the  '60s.  Many 
lessons  have  been  learnt  and  are  still  being  learnt  about  how  the  people  who  use 
them  relate  to  the  information  they  use  and  the  tasks  they  do.  How  many  of  these 
can  be  carried  over  into  ship  and  machinery  control?  What  are  the  similarities 
between  command  systems  and  modern  ship  control  systems?.  Both  of  them  are: 

used  by  people  with  a  fairly  broad  training 

used  to  monitor  uneventful  situations  for  most  of  their  service  lives 

intended  to  be  used  for  unpredictable,  intensive  bursts,  of  non  scheduled  activity 

capable  of  processing  and  storing  far  more  data  than  their  users  can  hope  to  absorb 
quickly,  (if  at  all) 
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give  the  feeling,  when  things  are  at  their  worst,  that  there  is  someone  out  there 
trying  to  make  everything  go  wrong! 

There  are,  of  course,  many  differences,  but  the  similarities  drawn  out  here  stem 
directly  from  the  most  important  common  element,  the  men.  By  taking  a  user 
centred  view,  complementary  to  the  equipment  centred  view,  there  are  many 
lessons  which  can  be  fed  across  form  other  areas. 

11.  LESSONS  FROM  COMMAND  SYSTEMS 

There  are  several  conspicuous  lessons  from  the  command  and  control 
experience  which  appear  to  carry  across. 

Building  a  system  with  the  sole  goal  of  throwing  data  at  the  men  will  swamp 

them. 

The  only  way  to  make  the  information  manageable  is  to  structure  it  in  ways 
which  relate  to  the  men's  knowledge  of  the  real  world  objects  it  represents  and  to 
provide  different  views  on  the  information  to  match  the  user's  task(s). 

Trying  to  establish  and  define  the  user's  conceptual  model  of  the  information 
base  and  the  problem  space  at  the  start  is  a  far  sounder  basis  for  design  than  allowing 
an  ad  hoc  model  to  emerge  from  the  implementation  of  the  software  and  then 
enforce  it  on  the  users. 

Capturing  the  real  requirement'  is  extremely  hard.  There  is  no  guaranteed 
way  to  succeed  in  every  detail,  but  there  are  many  widely  used  ways  nearly 
guaranteed  to  fail  in  several  important  details. 

'Users'  have  to  be  involved  as  they  have  a  unique  input  to  make,  but  merely 
building  straight  implementation  of  a  past  system  user's  wish  list  can  be  as  risky  as 
relying  on  knowledge  of  the  functions  of  the  equipment  being  used. 

No  reports  of  defects  does  not  mean  the  system  is  OK,  that  the  users  like  it  or 
that  they  can  use  it  to  any  useful  purpose;  it  means  it  is  behaving  in  the  same  way 
that  it  always  does.  If  that  way  is  no  good,  its  users  will  either  suffer  in  silence,  or 
simply  find  a  way  to  avoid  using  it. 

The  distinction  between  novices  and  experts,  (with  the  inference  that  technical 
systems  are  designed  for  experts  who  do  not  need  'fancy'  user  interfaces),  is  a  red 
herring.  Most  users  become  expert  in  some  aspects  of  the  system  but  less  so  in 
others.  In  the  less  familiar  areas,  they  need  to  be  able  to  be  reminded  as  they  go 
along,  ather  than  come  to  a  brick  wail.  This  is  helped  by  consistency  of  the  user 
interface,  (and  hence  the  available  system  functions),  across  different  parts  of  a 
system. 
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The  only  way  for  contractor  and  customer  to  know  whether  a  delivered  system 
is  'fit  for  use’  is  to  submit  it  to  representative  trials  with  real  users  performing 
realistic  tests  of  comprehension,  interpretation  and  action  to  defined  performance 
criteria.  Supplying  systems  on  these  terms  sharpens  the  minds  of  all  involved.  It 
can  only  sensibly  be  undertaken  when  human  engineering  is  applied  throughout  the 
development  cycle  and  where  the  customer  values  the  extra  quality  and  lower  risk 
which  come  from  doing  so,  but  it  will  lead  to  systems  which  perform  their  intended 
function  better  in  service. 

12.  CONCLUSION 

Many  machinery  control  systems  currently  being  built  have  user  interfaces 
which  would  be  recognisable  by  the  command  system  users  of  the  late  '60s.  Making 
such  systems  work,  relies  very  heavily  on  the  skills  and  mental  agility  of  the  people 
who  use  them.  It  is  likely  that  many  systems  'will  not  work'  in  the  sense  of  allowing 
their  users  to  do  the  tasks  they  were  intended  to  do  in  the  circumstances  where  it 
really  matters. 

Such  a  situation  is  not  new.  Experience  with  early  command  systems  in  use 
was  a  poor  shadow  of  the  visions  which  conceived  them.  The  man  is  the  common 
element,  and  it  is  reasonable  to  ask,  as  the  US  and  UK  Manprint  Programmes  do, 
whether  this  man,  with  this  training,  in  these  conditions,  can  use  this  system  to  do 
this  job.  The  answer  should  guide  the  development  of  the  system.  It  may  be  hard  to 
fit  the  system  to  the  man,  but  it  is  more  likely  to  succeed  than  ignoring  the  question. 
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1.  ABSTRACT 

The  Type  23  Frigate  is  a  trend-setter  in  the  integration  of 
ship  control  functions.  It  provided  an  excellent  platform  for  a 
static  and  dynamic  analysis  of  human  factors  in  the  ship  control 
centre.  The  methods  and  results  are  described  and  discussed  in 
this  paper.  The  static  analysis  revealed  many  good  design  features 
and  plenty  of  opportunities  for  improvements  to  the  present  and 
future  designs.  The  dynamic  analysis  pioneered  an  approach  which 
sought  to  measure  workload.  Mission  critical  tasks  were  defined 
and  then  filmed  whilst  being  performed  by  a  crew  in  a  simulator. 
Dynamic  analysis  of  the  resultant  video  proved  the  effectiveness 
and  efficiency  of  this  approach.  Task  snapshots  showed  where  the 
perceptual,  cognitive  and  psychomotor  loading  built  up  to  critical 
levels.  This  enabled  the  assessors  to  make  a  more  calculated 
judgement  than  has  hitherto  been  possible  on  the  degree  of 
performance  enhancement  achievable  from  good  human  factors  design. 
The  recommendations  from  this  work  provide  opportunities  for 
improving  ship  control  centre  designs  both  in  the  Type  23  Frigate 
and  future  ships.  They  are  especially  relevant  in  the  context  of 
the  current  pressures  on  manpower  and  the  need  to  enable  the  few 
watchkeepers  still  required  to  be  as  effective  and  efficient  as 
possible. 

2.  INTRODUCTION  AND  BACKGROUND 

The  Type  23  Frigate  is  a  trend-setter  in  the  integration  of 
control  and  surveillance  functions.  Designers  decided  at  an  early 
stage  to  integrate  ergonomically  all  the  facilities  necessary  in 
a  Ship  Control  Centre(SCC).  This  required  a  difficult  compromise 
in  the  need  to  optimize  between  the  very  different  demands  of 
peace  and  wartime  operation.  It  is  during  the  peacetime  cruising 
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conditions  that  constraints  on  manpower  make  the  need  to  minimise 
the  number  of  watchkeepers ,  paramount.  For  action  conditions  the 
design  must  provide  for  co-ordination  of  the  Marine  Engineer 
Officer's  fighting  responsibilities  and  must  enable  everybody 
closed  up  to  be  as  effective  as  possible.  There  is  no  universal 
remedy. 

About  30  square  meters  were  allocated  for  the  SCC.  The  design 
was  required  to  provide  a  man-machine  interface  (MMI)  for  peace  time 
cruising  conditions  manageable  by  a  watch  of  3  persons  with 
specified  skills.  The  same  design  had  to  provide  the  action  team 
with  the  facilities  required  for  the  control  and  surveillance  of 
damage,  stability,  propulsion,  auxiliaries,  electrical  generation, 
distribution  and  weapon  support  services. (Figure  1) 


Figure  1.  Type  23  ship  control  centre. 

Designers  started  with  the  requirements  for  propulsion  and 
auxiliaries  control  and  surveillance.  Tasks  were  defined  and 
analysed  and  an  initial  layout  was  proposed.  Liaison  with  similar 
work  being  undertaken  for  the  design  of  a  submarine  control  room 
led  particularly  to  the  double  layer  console  which  provides 
supervisors  with  a  central  and  slightly  raised  desk  behind  the 
operators.  This  was  assembled  as  a  mock-up  in  cardboard  and  then 
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reviewed  by  people  with  operational  experience  in  order  to  provide 
sufficient  confidence  to  proceed.  Definition  of  other  areas, 
especially  those  concerned  with  Nuclear,  Biological,  Chemical 
Defence  and  Damage  Control (NBCD)  followed  later. 

As  well  as  taking  a  modem  approach  to  the  design  of  the 
layout  of  the  SCC,  the  designers  adopted  the  new  technology  of  a 
distributed  digital  control  and  surveillance  system  using  D86 
hardware  based  on  the  INTEL  8086  processor.  D86  is  a  VTC 
proprietary  family  of  microprocessor  boards.  As  there  was  an 
element  of  risk  in  this  approach  it  was  decided  that  the  complete 
system  would  be  assessed  independently.  It  was  Intended  that  this 
should  enable  any  problems  to  be  resolved  before  they  hindered  the 
shipbuilding  programme  and  that  the  facility  should  give  the 
procurement  authorities  confidence  in  the  system. 

A  ship  set  of  Machinery  Control  and  Surveillance (MCAS) 
equipment  was  supplied  to  the  Admiralty  Research  Establishment 
(ARE) ,  West  Drayton  where  it  was  interfaced  to  a  simulator  of  the 
Type  23 's  machinery  and  electrical  systems.  The  simulated  system 
generated  signals  equivalent  to  the  transducer  outputs  of  the  real 
equipment  so  that  the  MCAS  system  was  performing  its  design  role. 
Additionally  the  consoles  for  the  SCC  were  positioned  as  in  the 
ship,  thereby  providing  an  excellent  opportunity  to  review  the 
human  factors (ergonomics)  achievements  of  the  design  by  the  static 
and  dynamic  analyses  described  in  this  article. 

3.  HUMAN  FACTORS  STUDIES 

A  programme  to  examine  human  factors  aspects  of  the  design  was 
Initiated  with  LIVEWARE  Human  Factors  Consultants  in  January  1989. 
Key  issues  included  the  need  to  quantify  human  performance  and  the 
practical  application  of  human  factors  techniques.  The  approach 
was  deliberately  kept  simple  so  that  all  findings  would  be  easily 
understood.  The  human  factors  study  programme  consisted  of  two 
phases . 

The  first  phase  involved  a  static  analysis.  Carried  out  at 
ARE  West  Drayton  the  system  ergonomic  layout  was  reviewed  without 
operators  present  but  with  explanation  from  a  subject  matter 
expert.  The  expert  was  videoed  during  the  explanation,  in  front 
of  each  panel  so  that  the  analyst  could  later  refer  to  specific 
panels  in  laboratory  conditions.  This  technique  proved  most 
effective  and  simple  to  implement. 

The  second  phase  involved  a  dynamic  analysis  using  video 
recordings  of  operators  performing  actual  mission  tasks  on  the 
simulator  at  HHS  SULTAN,  Gosport.  Inevitably,  the  work  produced 
criticism  of  the  Type  23  Frigate  SCC.  Although  important,  this 
criticism  must  be  viewed  in  the  context  of  the  notable  achievements 
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of  the  designers.  The  application  of  digital  technology  and 
ergonomics  has  achieved  a  design  which  needs  only  3  watchkeepers 
for  a  peace  time  watch  compared  to  the  6  required  in  a  Type  22 
Frigate.  Such  a  50%  reduction  in  watchkeeping  numbers  between 
successive  classes  of  ships  is  dramatic  and  extremely  welcome  in 
this  current  era  of  manpower  shortages. 

3.1  Static  analysis 

For  the  static  analysis  the  SCC  was  reviewed  from  console 
layout,  through  panel  design  down  to  the  design  of  displays  and 
controls,  including  local  controls.  Judgements  about  human  factors 
aspects  of  the  design  were  with-held  until  the  operation  of  each 
panel  was  fully  understood. 

Although  there  is  much  data  in  the  literature  on  how  to  design 
ergonomic  control  rooms,  there  is  very  little  practical  advice 
aimed  at  time-efficient  analysis  within  commercial  constraints. 
For  this  programme  the  SCC  layout  was  reviewed  from  5  fundamental 
design  criteria: 

(1)  Positioning  of  devices  for  frequency  of  use. 

(2)  Positioning  for  sequence  of  operation. 

(3)  Positioning  for  safety  of  operation. 

(4)  Grouping  of  devices  by  function  and  task. 

(5)  Choice  of  display  medium  according  to  the  task. 

The  static  analysis  drew  attention  to  many  good  applications 
of  human  factors.  For  example,  the  concept  of  a  concentric  console 
arrangement  splitting  the  supervisory  function  from  the 
watchkeeping  functions  achieves  a  natural  task  hierarchy. 

The  static  analysis  also  revealed  opportunities  for 
improvements  to  the  design.  The  main  areas  involved  aspects  which 
might  lead  to  an  incorrect  response  in  an  emergency.  For  example, 
all  control  buttons  should  be  provided  with  both  tactile  and  visual 
feedback  of  their  operation.  Controls  dis-associated  from  their 
relevant  displays  can  result  in  a  tortuous  feedback  loop  for  the 
operator.  Controls  which  are  crucial  to  mission  success  or  which 
function  differently  should  look  and  feel  different  so  that  they 
are  not  confused.  The  amount  of  information  on  a  display  should 
be  limited  to  that  which  is  absolutely  essential.  Technology  has 
facilitated  almost  limitless  opportunities  for  presenting  data  and 
the  engineer  must  not  fall  into  the  tempting  trap  of  displaying 
permanently  "nice  to  have"  data. 
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Figure  2:  Propulsion  panel 


Display  policies  vary  around  the  panels  depending  upon  when 
the  design  was  finally  settled.  Similarly,  software  access  codes 
for  parameters  vary  between  parts  of  the  system.  Several  such 
inconsistencies  Illustrate  that  the  procurers  of  future  systems, 
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especially  where  large  nuahers  of  parameters  are  Involved,  will 
need  to  encourage  more  systems  co-ordination  from  an  early  stage 
and  more  regular  reviews  of  their  achievements  during  the  design 
programme. 

3.2_  Dynamic  analysis 

The  static  analysis  looked  at  the  basic  disposition  of 
devices  from  fundamental  human  factors  principles.  The  dynamic 
analysis  measured  how  well  the  system  performed  in  realistic  use. 
To  the  hardware  and  software  engineer  the  silicon  chip  and  the  byte 
are  key  attributes  determining  system  performance.  To  the  human 
factors  specialist  it  is  the  human  operator  and  the  design  of  the 
interface,  tasks  and  environment  that  determine  optimum  human  and 
therefore  overall  system  performance.  This  is  reflected  in  the 
method  used  for  the  dynamic  workload  analysis  summarised  as 
follows: 

(1)  DEFINE  MISSION  CRITICAL  TASKS (MCTs). 

(2)  DEVELOP  WORKLOAD  MODEL. 

(3)  PERFORM  VIDEO  ANALYSIS. 

(4)  TEST  WORKLOAD  MODEL. 

(5)  PRODUCE  WORKLOAD  CHARTS. 

(6)  ANALYSE  AND  QUANTIFY  DESIGN  IMPROVEMENTS 

The  Type  23  SCC  simulator  at  HMS  SULTAN  provided  an  excellent 
platform  on  which  to  carry  out  the  dynamic  analysis.  As  in  phase 
1,  video  analysis  was  selected  as  the  best  means  of  capturing  the 
necessary  data  for  subseguent  analysis.  A  subject  matter  expert 
accompanied  the  analyst  to  explain  what  was  going  on  during  the 
mission. 


a.  Define  MCTs.  First  the  tasks  needed  to  be  defined,  since 
there  are  many  tasks  in  running  a  complex  system  it  was  considered 
more  efficient  to  focus  on  the  Mission  Critical  Tasks  (MCTs) . 
Improving  performance  of  these  tasks  would  be  the  most  cost- 
effective  way  to  maximise  potential  enhancements  to  the  system. 
The  following  are  examples  of  MCTs  which  were  identified  in 
consultation  with  the  designers  and  operators: 

MCTl:  FIRE  IN  MACHINERY  SPACES 

MCT2:  TELEGRAPH  ORDERS 

MCT3:  START  PORT  GAS  TURBINE 
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MCT4;  CRASH  STOP  ASTERN  MANOEUVRE 


b.  Define  workload  model.  Measurement  of  workload  is  based 
on  workload  being  a  function  of  4  fundamental  concepts: 


(1) 

THE  XASK 

-  How  difficult 

(2) 

THE  QPERATOR 

-  How  skilled 

(3) 

THE  SYSTEM 

-  How  well  configured 

(4) 

THE  ENVIRONMENT 

-  How  comfortable 

Thus:  LOAD  =  f(TOSE) 


The  Xask  is  concerned  with  what  the  operator  does  with  the 
equipment  at  his  disposal.  For  example,  the  secpience  of  operating 
controls  and  looking  at  displays  is  part  of  the  task,  as  is  making 
decisions  on  courses  of  action.  For  any  piece  of  equipment,  the 
arrangement  of  tasks  can  have  a  significant  effect  on  the 
performance  of  the  crew  with  that  equipment.  This  study  involved 
observation  of  tasks  which  were  already  rigidly  defined. 

The  (Operator,  his  skill  and  his  training  are  also  significant 
performance  determinants.  The  investment  in  the  Type  23  Simulator 
at  HMS  SULTAN  is  testimony  to  the  Royal  Navy's  commitment  to 
training. 

The  System  and  how  it  is  configured  were  major  reasons  for 
undertaking  this  study  of  the  way  in  which  the  controls  and 
displays  are  laid  out  on  the  panels,  in  the  space  available.  This 
branch  of  ergonomics  is  sometimes  called  the  Man-Machine 
Interface (MMI)  and  is  part  of  the  whole  study  of  human  factors. 

The  £nvironment  refers  to  the  surroundings  within  which  the 
operator  is  working.  For  example,  other  crew  members,  noise,  heat 
and  lighting  can  significantly  affect  operator  performance. 

In  summary,  of  the  four  determinants  of  human  performance, 
this  study  concentrated  more  on  the  System  and  how  the  control  room 
could  be  enhanced  by  better  layout  of  controls  and  displays. 

In  performing  effectively,  operators  depend  upon  their  own 
human  skills.  There  are  3  fundamental  human  skills: 

1  PERCEPTUAL  -  Receive  information 

2  COGNITIVE  -  Process  that  information 
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3  PSYCHOMOTOR  -  Operate  a  control  device 

Perceptual  skills  are  those  concerned  with  our  ability  to 
receive  information,  that  is,  observation.  The  human  perceptual 
system  has  five  senses  to  achieve  this,  the  predominant  sense  being 
the  eyes.  An  example  of  a  perceptual  skill  is  the  ability  of  a 
pilot  to  observe  another  aircraft  or  the  ability  of  an  operator  to 
notice  a  warning  on  the  operator's  console. 

Cognitive  skills  are  those  concerned  with  our  ability  to 
process  information  and  make  decisions.  An  example  of  a  cognitive 
skill  is  the  ability  of  a  judge  to  pass  sentence  on  a  defendant  or 
the  ability  of  an  operator  to  decide  what  course  of  action  to  take 
following  a  warning. 

Psychomotor  skills  are  those  concerned  with  our  ability  to  act 
upon  the  information  we  receive.  An  example  of  a  psychomotor  skill 
is  the  ability  of  a  tennis  player  to  hit  an  effective  shot  or  the 
ability  of  an  operator  to  take  corrective  action  or  simply  make  a 
control  adjustment. 

In  developing  the  workload  model  it  can  be  seen  that,  in 
summary,  the  four  determinants  of  workload  must  be  understood 
together  with  the  three  basic  human  skills.  A  typical  workload 
model  such  as  that  illustrated  in  Figure  3,  shows  a  task  snapshot 
consisting  of  2  observations  Rl  and  R2,  1  decision,  PI  and  4 
actions,  Al-4  over  a  period  of  time  from  0-T  seconds,  the  length 
of  which  depends  on  the  task  sampling  period.  Two  of  the  actions 
are  seen  to  be  simultaneous.  This  is  a  simplified  graph  of  a  task. 
In  practice,  the  operator  "footprints"  of  workload  are  more  complex 
although,  as  more  charts  are  created,  designers  will  quickly 
recognize  high  workload  patterns  as  opposed  to  low  workload 
patterns.  They  will  then  be  able  to  make  early  design  alterations 
to  smooth  the  workload  over  the  task  period.  Such  remedial  action 
may  involve  re-designing  the  task,  providing  more  system  automation 
and  removing  an  operator,  re-training  the  operator  or  improving  the 
environment. (Figure  3) 
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c.  video  analysis.  Video  analysis  was  found  to  be  very 
effective  for  task  analysis.  Benefits  include:  a  total  record  of 
the  events  in  sound  and  vision;  capture  of  a  lot  of  data  where  note 
taking  is  prohibitive;  the  facility  to  replay  the  precise  events, 
and  a  convenient  medium  for  presentation  and  demonstration 
purposes.  The  first  MCT  was  analysed  to  test  the  workload  model. 

d.  Test  workload  model.  The  video  for  the  first  MCT  was 
analysed  with  a  stop-watch  under  laboratory  conditions  to  separate 
each  event  over  the  time  period  and  categorise  each  action  into  the 
3  basic  human  skills.  This  was  a  pains  taking  process  which  would 
have  been  much  easier  had  a  clock  been  available  within  the  video. 
The  result  was  a  table  summarising  the  events,  the  time  and  the 
skills  used.  The  workload  model  was  refined  and  the  analysis 
technique  improved  before  the  remaining  MCTs  were  filmed.  An 
example  of  an  actual  mission  critical  task  snapshot  is  shown  at 
figure  4. 
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Figure  4.  Mission  critical  task  snapshot. 
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e.  Produce  workload  charts.  When  the  workload  model  was 
perfected,  the  remaining  MCTs  were  filmed.  Workload  charts  were 
produced,  resulting  in  nine  graphs  in  total,  one  for  each  MCT. 
Figure  4  above  is  one  example  of  these  nine  graphs  and  shows  the 
workload  in  the  number  of  "actions"  for  each  of  the  three  human 
skills.  The  lower  performance  curve  shows  the  total  load  over  that 
snapshot.  This  is  a  siunmation  of  the  three  individual  loads 
incurred  on  the  operator. 

f .  Analyse  and  quantify  design  improvements.  Analysis  of  the 
videos  of  the  MCTs  highlighted  some  interesting  features.  Alarm 
systems  must  be  designed  to  attract  operator  attention  to  the 
source  of  the  alarm,  both  visually  and  audibly.  This  will  save 
time,  reduce  errors  and  enable  the  operator  to  use  the  system  more 
effectively.  All  system  users  can  be  disturbed  by  alarms  which  are 
too  loud.  Whilst  alarms,  by  definition,  must  be  instantly 
detected,  they  must  not  startle  the  operator  into  confusion  and 
inaction.  Ideally  the  alarm  annunciator  should  gradually  increase 
in  volume  and  be  designed  to  encourage  the  operators  to  look  in  the 
correct  direction.  The  annunciator  should  be  positioned  centrally 
thereby  removing  the  temptation  for  the  operator  to  turn  around 
each  time  an  alarm  sounds. 

The  videos  show  examples  of  where  operators  misinterpret  their 
primary  instrumentation,  port  for  starboard,  for  example.  CCTV 
systems  are  now  available  and  could  be  beneficially  fitted  for 
machinery  surveillance.  Operators  able  to  confirm  their 
conclusions  by  reference  to  such  a  secondary  surveillance  system 
are  more  likely  to  avoid  erroneous  actions.  Reports  from  the 
Boeing  disaster  at  Kegworth  illustrate  this  because  they  suggest 
that  the  pilot  may  have  saved  the  aircraft  had  he  been  able  to  see 
the  engines.  Cameras  are  now  being  fitted  to  certain  British 
Airways  airliners. 

The  videos  also  illustrate  that  operators  have  difficulty 
interpreting  a  large  number  of  indications  quickly.  Previous 
generation  instrumentation  consisted  of  separate  display  devices 
for  each  transducer.  Then  Instruments  combined  data  within  one 
display  until  limited  by  the  space  available.  Now,  a  virtually 
unrestricted  amount  of  information  can  be  displayed  using  computer- 
driven  paging  facilities. 

A  composite  of  hardwired  devices  and  multi-function  displays, 
as  in  the  Type  23  Frigate,  seems  appropriate  for  future  HMIs. 
However,  a  balance  must  be  achieved  and,  in  particular,  indications 
on  a  console  must  be  kept  to  a  minimum.  A  computer-based  secondary 
surveillance  system  provides  an  ideal  way  to  amplify  information 
but  must  provide  a  user-friendly  dialogue  and  quick  access  to  the 
required  data  page.' 


3.92 


consideration  of  the  "task  snapshots"  suggests  that  workload 
has  a  maximum  and  minimum  level  for  optimum  performance.  If 
loading  Is  too  high  the  operator  will  miss  information.  If  It  Is 
too  low  the  operator  will  become  bored.  Good  task  design  should 
provide  an  optimum  level  of  activity.  The  analysis  in  this  case 
highlighted  areas  in  which  further  automation  could  beneficially 
remove  workload  peaks. 

4.  BENEFITS  FOR  THE  FUTURE 

The  analyses  have  shown  that  there  are  many  good  human  factors 
aspects  to  the  Type  23  Frigate  MCAS  system.  The  hierarchy  of 
alarms  and  warnings,  the  sighting  of  displays  above  controls,  and 
the  concentric  console  arrangement  splitting  yet  combining  the 
operator,  supervisor  and  MEO  tasks,  are  all  examples.  The  effort 
to  achieve  an  ergonomic  design  has  been  worthwhile  and  provides 
firm  principles  from  which  to  propose  improvements  for  future 
ships.  The  videos  have  also  enabled  assessors  to  draw  the  early 
attention  of  designers  and  operators  to  areas  of  risk  in  the 
layout. 

The  assessment  quantified  the  potential  reduction  of  workload 
thereby  giving  procurement  authorities  a  positive  basis  on  which 
to  assess  improvement  proposals.  The  techniques  used  are  simple, 
practical  and  cost-effective  to  apply.  Potential  benefits 
demonstrate  the  value  of  such  human  factors  reviews  and  if 
improvements  to  the  design  are  Implemented  then  there  should  be 
consequential  savings  on  operator  training  and  improved  ship 
performance  and  safety. 

Analysis  of  perceptual  load  illustrates  that  an  operator 
should  not  be  required  to  receive  2  sources  of  information 
simultaneously.  Highly  skilled  operators  appear  to  be  multi¬ 
processing  but  are  in  fact  either  "chunking" (grouping)  discrete 
tasks  together  and  treating  them  as  one  action  or  are  switching 
rapidly  from  action  to  action.  A  virtuoso  pianist  exhibits  both 
of  these  human  traits,  however,  for  multi-populations,  the  human 
factors  analyst  must  design  for  the  least  skilled  rather  than  the 
most  skilled  person. 

Similarly,  an  operator  should  not  be  required  to  make  more 
than  one  decision  simultaneously.  The  action  of  making  a  decision 
is  a  single  channel  cognitive  operation.  There  is  another  kind  of 
mental  loading  related  to  decision  making  but  concerned  only  with 
the  amount  of  data  which  can  be  held  in  short  term  memory.  This 
is  sometimes  also  called  "chunking",  and  is  part  of  short  term 
recall  and  the  way  this  relates  to  activation  of  long  term  memory. 
Operators  should  not  be  required  to  hold  more  than  5  chunks  of  data 
in  short  term  memory  at  any  one  time.  These  chunks  are  not  mental 
actions  as  such,  but  are  a  function  of  the  span  of  attention. 
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Under  stress  psychomotor  and  perceptual  performance  are 
enhanced  until  breaking  point  renders  them  ineffective.  Cognitive 
performance,  on  the  other  hand,  rapidly  degenerates.  The  more 
decisions  facing  the  operator,  the  longer  it  takes  with  mental  load 
increasing  exponentially  with  the  number  of  decisions  required. 

The  psychomotor  load  should  be  limited  to  operating  two 
controls  simultaneously,  especially  for  unfamiliar  tasks.  In  a 
car,  the  driver  steers  and  changes  gear  together  easily.  This  may 
seem  small,  but  if  this  rule  is  followed,  it  errs  on  the  safe  side 
and  makes  allowance  for  less  skilled  operators  performing  new  tasks 
in  hostile  situations. 

If  these  3  rules  for  perceptual,  cognitive  and  psychomotor 
load  are  not  violated  then  an  operator  should  not  be  required  to 
perform  collectively,  more  than  3  actions  simultaneously.  A  driver 
might  steer (a  psychomotor  skill),  observe  the  road  ahead (a 
perceptual  skill)  and  think  about  the  worsening  weather  (a  cognitive 
skill)  simultaneously.  Such  a  composite  of  3  actions  should  be 
regarded  as  a  limit  if  the  philosophy  for  the  least  able  operator 
is  to  be  followed.  The  acceptable  limit  for  these  workload  levels 
can  be  more  easily  understood  by  looking  back  at  Figure  4. 

The  static  and  dynamic  analyses  were  conducted  on  a  completed 
design.  Looking  head,  the  principles  of  human  factors  analysis  and 
design  must  be  applied  early  to  new  designs.  Human  factors  aspects 
should  then  be  addressed  continually  as  an  Integral  part  of  the 
design,  development  and  delivery.  The  process  of  human  factors 
analysis  is  summarised  in  Table  1  which  illustrates  that  the 
essential  output  of  analysis  is  the  Top  Level  Specification  for  the 
user. (Table  1) 

Table  1.  Human  factors  analysis  method. 
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The  Top  Level  Specification  can  then  be  used  by  all  members 
of  the  design  team  during  the  design  phase.  The  human  being  is  a 
dynamic  and  variable  organism.  Tolerances  in  design  for  humans 
tend  to  reflect  this  variability.  Any  human  factors  technique  must 
respect  this  and  avoid  wasting  time  and  money  by  placing  a  tighter 
tolerance  on  methods  which  try  to  inflict  too  much  precision. 
Urgent  issues  should  be  addressed  first  in  a  clear  and  simple  way. 
This  practical  approach  will  result  in  an  Increased  probability  of 
human  factors  issues  being  resolved.  A  complicated  method  risks 
being  abandoned  all  together.  As  illustrated  by  this  programme  the 
potential  reduction  in  workload  can  be  simply  quantified  thereby 
providing  a  positive  basis  for  the  assessment  of  improvement 
proposals.  The  design  method  is  illustrated  in  Table  2. 

Table  2.  Human  factors  design  method. 
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All  such  work  relies  upon  accurate  assessments  of  the  tasks, 
in  this  case  the  mission  critical  ones.  These  must  be  thoroughly 
understood  and  need  considerable  input  from  the  end  user, 
instructors  being  especially  useful.  Once  the  tasks  are  agreed 
the  human  factors  specialist  still  needs  advice  from  a  subject 
matter  expert  with  extensive  professional  knowledge  and  operating 
experience.  This  person  is  needed  to  advise  during  the  observation 
process  and  subsequently  to  guide  opinion  on  the  practicality  of 
improvement  suggestions.  The  design  phase  starts  with  a  plan  which 
alms  to  allocate  tasks  appropriately  to  humans.  The  output  of  the 
design  phase  is  a  specification  for  the  first  prototype 
system. (Table  2  above) 

5.  CONCLUSIONS 

Consideration  of  human  factors  should  be  an  integral  and  early 
part  of  the  design  and  development  process.  It  will  enhance 
operating  commonality  between  systems  by  imposing  interfaces 
designed  to  match  normal  human  stereotypes.  The  evidence  has 
illustrated  that  human  factors  assessments  can  give  early  warning 
to  areas  of  risk,  and  the  potential  for  improvements  can  be  cost- 
effectively  quantified  using  techniques  such  as  the  "task 
snapshots"  described  in  this  article. 

This  human  factors  assessment  has  identified  possible  design 
changes  which  could  contribute  to  further  reductions  in  workload 
and,  equally  importantly,  to  the  improvement  in  effectiveness  and 
efficiency  of  those  operating  future  warships.  The  application 
of  CCTV  within  machinery  spaces  and  the  need  to  design  carefully, 
the  alarm  annunciator,  are  good  examples. 

The  views  expressed  in  this  paper  are  those  of  the  authors  and 
do  not  necessarily  reflect  the  views  of  the  Ministry  of  Defence. 

©Controller,  Her  Majesty's  Stationery  Office  London  1990 
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1.  ABSTRACT 

General  purpose  data  buses  offer  advantages  to  combatant 
warships  which  have  not  always  been  well  understood.  In  this 
paper,  the  role  of  general  purpose  data  busing  in  modern  surface 
combatants  is  explained,  and  the  application  of  the  Data  Multiplex 
System  (OMS)  AN/USQ-82(V)  in  the  U.S.  Navy's  new  Arleigh  Burke 
class  of  guided  missile  destroyers  is  examined.  It  is  important  to 
note  that  this  paper  is  not  about  a  data  bus;  it  is  about  the 
application  of  data  busing.  It  is  about  real  world  issues  of 
design  compatability,  equipment  interfacing,  and  systems 
engineering  which  arise  when  systems  which  were  conceived  and 
designed  in  Isolation  must  be  combined  to  form  an  integrated  ship 
system.  Some  of  these  issues  are  clear  cut  and  become  obvious 
during  design;  others  are  not  so  simple  to  diagnose  and  do  not 
become  apparent  until  integration  testing  has  commenced.  This 
paper  will  describe  the  issues,  their  resolution,  and  the 
characteristics  a  general  purpose  data  bus  must  have  to  allow 
resolution  of  these  issues  without  causing  major  impacts  on  user 
systems . 

2 .  INTRODUCTION 

Naval  surface  combatants  are  unique  among  military  platforms 
in  that  they  Include  a  very  large  assortment  of  diverse  systems  and 
subsystems.  The  combat  system  of  a  surface  combatant  is  a  good 
example  of  this,  since  it  typically  consists  of  separate  subsystems 
designed  for  air,  surface,  and  subsurface  target  engagements.  The 
engineering  plant,  the  navigation  system,  the  damage  control 
system,  and  the  steering  control  system  are  other  examples  of 
systems  which,  in  major  surface  combatants,  are  quite  different  one 
from  another,  and  are  composed  of  a  variety  of  technologies  in 
their  lower-tier  subsystems.  These  different  systems  and 
subsystems  are  normally  designed  and  built  by  different 
Navy/industry  teams,  each  one  targeting  a  specific  set  of  problems 
and  using  a  particular  design  approach  which  may  have  little  in 
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common  with  the  designs  of  other  subsystems.  Frequently  the 
subsystem  design  is  optimized  to  perform  the  subsystem's  mission 
with  little  regard  to  optimizing  the  design  of  the  ship  as  a  whole. 
Add  to  this  the  variability  in  age  of  these  multiple  subsystems 
(all-new  designs  for  any  individual  ship  class  would  result  in  a 
prohibitively  expensive  ship,  not  to  mention  an  unreasonably  high 
schedule  risk) ,  and  it  becomes  clear  that  Naval  ships  are  unlikely 
ever  to  consist  of  a  homogeneous  set  of  parts. 

To  further  exacerbate  the  non-homogeneous  nature  of  major 
surface  combatants,  it  is  not  realistic  to  expect  any  universal 
standard  to  be  developed  for  any  single  aspect  of  a  ship's  systems 
which  will  be  viable  during  the  ship's  30+  year  lifespan.  In  fact, 
for  major  shipbuilding  programs  such  as  the  U.S.  Navy's  DDG  51 
program,  it  is  unlikely  that  the  standards  will  remain  constant 
throughout  the  building  phase  of  the  ship  class.  Advances  in 
technology  are  frequently  incorporated  during  the  building  phase, 
resulting  in  "subclasses"  or  "flights"  of  a  shipbuilding  program. 
Between  ship  classes,  of  course,  there  is  even  less  homogeneity. 

The  advantages  of  distributed  processing  have  been  enumerated 
in  many  sources,  and  such  an  architecture  is  clearly  the  trend  in 
control  system  architectures  today.  Highly  survivable  control 
system  networks  can  be  designed  in  which  multiple  processors  and 
displays  located  strategically  throughout  the  ship  can  share  or 
swap  roles  as  the  situation  demands.  In  present  systems,  these 
shared  functions  are  primarily  built  into  individual  systems,  not 
between  systems.  However,  there  is  no  reason  to  believe  that 
future  ship  designs  would  not  incorporate  redundant  architectures 
across  system  boundaries. 

To  implement  practical  distributed  control  systems  which 
capitalize  on  the  flexible,  adaptable  nature  of  digital  processors 
is  virtually  Impossible  without  data  busing.  Not  only  would  it 
quickly  create  an  unmanageable  mass  of  signal  interface  cabling, 
but  it  would  soon  overwhelm  the  most  potent  computer  input/output 
controllers  available.  Combat  systems,  which  were  the  first  to 
implement  distributed  control  architectures  in  large  scale,  have 
seen  this  problem  creeping  up  over  the  past  20  years  or  so.  Newer 
control  system  designs,  such  as  the  US  Navy's  Machinery  Control 
System  (MCS)  and  Steering  Control  System  (SCS) ,  are  attempting  to 
avoid  this  problem  by  relying,  at  least  in  part,  on  the  services  of 
a  general  purpose  data  bus. 

3.  REQUIREMENTS  FOR  A  GENERAL  PURPOSE  DATA  BUS 

A  general  purpose  data  bus  is  one  which  has  been  designed  to 
accommodate  data  transfer  among  diverse  systems  and  equipment.  It 
must  be  capable  of  handling  the  data  transfer  needs  of  multiple 
control  systems  communicating  simultaneously  without  these  systems 
interacting  in  any  way  and  without  requiring  the  designers  of  these 
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systems  to  know  or  care  about  what  other  systems  are  sharing  the 
data  bus.  A  general  purpose  data  bus  does  not  attempt  to  impose  a 
single  standard  on  equipment  Interfaces.  It  must  accommodate 
non-digital  users  (analog,  synchro,  discrete,  etc.)  as  well  as  a 
variety  of  digital  interfaces  each  with  its  own  appropriate 
protocols . 

With  the  above  in  mind,  it  is  not  difficult  to  define  some  of 
the  high  level  requirements  placed  on  this  general  purpose  bus: 

•  The  general  purpose  bus  must  be  capable  of  supporting  a  large 
number  and  variety  of  user  interface  connection  points.  Use  of 
digital  technology  at  the  source  user  end  as  well  as  the  sink  user 
end  of  the  communications  link  could  reduce  the  total  number  of 
interfaces  needed,  but  for  the  foreseeable  future  there  will 
continue  to  be  a  plethora  of  non-digital  equipment  such  as  pump 
controllers,  valve  controllers,  environmental  sensors,  and  display 
panels.  As  an  example,  in  the  DDG  51  application  there  are  1617 
interfaces  to  the  Data  Multiplex  System,  only  27  of  which  are 
digital . 

•  A  bus  which  provides  service  to  critical  ship  systems  must  be 
both  reliable  and  survivable.  In  fact,  general  acceptance  of  such 
a  bus  depends  on  overall  survivability  surpassing  that  of  older 
hardwired  designs. 

•  Finally,  the  long  expected  life  of  surface  combatants  today 
demands  that  the  bus  system  support  considerable  growth  in  terms  of 
quantity  and  type  of  users  serviced,  and  in  terms  of  its  own 
upgradability.  As  the  user  device  technology  is  upgraded  in  a 
ship's  modernization  periods,  the  bus  must  be  capable  of  keeping  up 
with  user  service  demands. 

This  paper  traces  the  practical  aspects  of  the  application  of 
the  first  general  purpose  data  bus  system  in  the  U.S.  Navy:  the 
Data  Multiplex  System  ^MS)  AN/USQ-82(V)  in  the  DDG  51  class  of 
destroyers.  The  topic  is  covered  from  the  point  of  view  of  user 
systems  and  system  integration  issues  rather  than  from  a  DMS- 
related  perspective.  Many  of  the  concepts  illustrated  would  apply 
to  any  general  purpose  bus  implementation,  and  are  presented  in  a 
"lessons  learned"  format.  Thus,  rather  than  describe  the  structure 
of  DMS  in  isolation,  this  paper  investigates  the  evolution  of  the 
user  device  networks,  the  problems  encountered,  and  solutions 
implemented.  Some  of  the  solutions  consisted  of  making  use  of 
DMS's  inherent  flexibility.  This  serves  to  illustrate  some  of  the 
features  needed  in  data  bus  systems  generically.  A  more  detailed 
discussion  of  DMS  structure  and  operation  was  given  in  (1)  and  (2). 

Perhaps  the  most  telling  message,  however,  is  that  with  all  of 
the  Interface  signal  and  protocol  questions  which  have  surfaced 
between  the  early  Contract  Design  and  the  late  Detail  Design  phases 
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of  the  DDG  51  program,  never  were  the  internal  DMS  data  bus 
protocols  the  issue.  All  of  the  problems  and  solutions  related  to 
the  bus-to-user  interfaces.  This  is  where  there  seems  to  be 
constant  demand  for  flexibility  and  adaptability. 

The  Appendix  presents  an  Open  System  Interconnection  ^ (OSI) 
model  view  of  DMS.  The  OSI  representation  illustrates  graphically 
some  of  the  concepts  which  will  be  discussed,  such  as  how  a  general 
purpose  bus  can  be  used  to  support  communications  between  otherwise 
incompatible  systems. 

4.  APPLICATION  DESIGN  OF  THE  DDG  51  DATA  BUS 

Very  early  in  the  DDG  51  design  cycle,  it  had  been  decided 
that  a  general  purpose  data  bus  would  be  installed  to  save  weight 
through  reduction  in  the  ship's  signal  cabling,  reduce  the  cost  of 
future  upgrades,  and  provide  more  survivable  data  transfer  paths. 
The  networking  aspects  of  a  data  bus  were  also  required  by  some  of 
the  new  subsystems  being  developed  for  this  ship  class. 

To  assist  in  the  application  engineering  required  to  configure 
DMS  for  a  specific  ship  class,  two  automated  tools  were  applied. 
The  first,  the  Application  Design  Automation  Program  (ADAP) , 
assigns  users  to  input-output  channels  while  minimizing  user-to-DMS 
interface  lengths,  and  defines  an  optimal  message  management 
structure  within  DMS.  The  second,  the  Timing,  Event,  and  Load 
Simulation  (TELS) ,  performs  a  simulation  of  the  data  bus  and  its 
constituent  parts.  The  output  from  ADAP  is  used  as  the  TELS  input. 
TELS  then  provides  the  application  designer  with  the  bus  and 
terminal  loading  data.  These  tools  had  served  the  DMS  design  team 
well  during  the  development  program,  but  proved  to  have 
deficiencies  when  applied  to  the  first  "real  world"  application  of 
DMS. 


Early  in  the  contract  design  phase  it  became  necessary  to 
modify  ADAP.  At  first  blush,  the  goal  of  minimizing  interface 
cable  length  between  users  and  DMS  appears  reasonable.  However,  in 
the  face  of  real  world  design  issues,  strict  adherence  to  this  goal 
had  to  be  abandoned.  During  the  contract  design  phase  of  a 
shipbuilding  program,  the  design  is  still  somewhat  fluid,  but 
design  products  (drawings,  specifications,  etc.)  are  being 
produced.  The  addition  or  deletion  of  a  single  user  could  result 
in  the  reassignment  of  literally  dozens  of  user  channels  to 
reoptimize  the  ADAP  parameters.  Clearly  the  impact  of  such 
reassignment  was  unacceptable  in  terms  of  both  time  and  costs.  A 
decision  was  made  to  "freeze"  the  existing  channel  assignments. 
Users  could  still  be  added  or  deleted,  but  this  addition/ deletion 
would  have  no  bearing  on  the  channel  assignment  of  existing  users. 
Thus,  only  the  design  products  applicable  to  the  users  being 
changed  required  updating. 
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ADAP  was  therefore  extensively  changed  to  better  accommodate 
the  needs  of  real  ship  design  programs.  The  current  structure  of 
ADAP  can  best  be  described  as  a  rule-based  database.  Rule-based 
because  ADAP  must  check  that  all  Interface  and  message  assignments, 
and  all  signal  and  message  control  firmware  are  made  consistent 
with  prescribed  DHS  requirements  and  constraints. 

The  new  ''hap  is  also  a  database  which  contains  all  pertinent 
information  the  user  device  interfaces  with  DMS,  such  as  the 
location  of  the  user,  the  source(s)  or  sink(s)  of  data  for  that 
user,  signal  update  rates,  type  of  protocol  used,  type  of  interface 
signal,  jack  number,  and  so  on.  This  database  is  the  fundamental 
tool  used  in  configuration  management  of  the  bus  system,  and 
programs  have  been  developed  to  allow  contract  drawings,  interface 
design  specification  documents,  technical  manuals,  test  documents, 
and  shipyard  databases  to  be  updated  automatically  from  ADAP  files. 

When  communications  issues  surfaced  in  the  DDG  51  Machinery 
Control  System  (MCS) ,  TELS  did  not  have  the  capability  necessary  to 
assist  application  designers  in  resolving  these  issues.  TELS  has 
proven  to  be  remarkably  accurate  at  predicting  measures  of  bus 
performance.  In  popular  data  busing  parlance,  TELS  is  concerned 
with  the  inter-terminal  communications.  However,  in  real  world 
applications,  bus  performance  can  be  very  misleading  measure  of 
what  is  actually  occurring.  Bus  system  performance  can  be  adequate, 
yet  problems  at  the  user  interface  level  may  still  exist. 
Additional  effort  was  therefore  needed  to  study  the  effectiveness 
of  MCS  processor  communications  via  DMS.  This  effort  involved 
careful  modeling  of  the  communications  evolutions  beyond  the 
boundaries  of  the  DMS  terminals  -  to  include  mechanisms  which  are 
critical  to  the  overall  communications  process  but  which  are  beyond 
the  scope  of  TELS. 

For  analysis  of  the  DDG  51  Machinery  Control  System  (MCS) ,  the 
U.S.  Navy  developed  an  MCS  communications  simulation  that  treats 
the  entire  DMS  as  a  "black  box",  in  order  to  evaluate  proposed 
modifications  to  user  protocols.  The  lesson  learned  here  is  that 
the  data  bus  simulation  should  extend  to  users'  application  program 
interface,  and  the  user  simulation  ought  to  be  easily  mated  to  the 
bus  simulation  to  allow  for  analysis  of  complete  user  to  user 
communications . 

5.  AEGIS  COMBAT  SYSTEM 

All  systems,  Including  the  combat  system,  were  initially 
considered  as  potential  DMS  subscribers  in  DDG  51.  The  AEGIS 
combat  system,  which  had  already  been  installed  in  CG  47  Class 
cruisers,  was  a  well  developed  network  of  computers  and 
peripherals.  This  network  uses  point-to-point  cabling  for 
intercomputer  and  computer  to  peripheral  communications. 
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When  DMS  was  proposed  for  use  in  the  AEGIS  combat  system,  the 
concept  was  merely  to  use  DMS  as  a  direct  replacement  for  the 
existing  intercomputer  and  computer  to  peripheral  cables.  A 
redesign  of  the  existing  AEGIS  architecture  to  one  which 
capitalizes  on  a  data  bus  was  not  contemplated,  as  it  would  have 
involved  significant  efforts  by  communities  outside  of  DMS.  Because 
DMS  was  proposed  this  way,  the  benefits  to  a  mature  computer 
network  such  as  AEGIS  were  small  from  a  capabilities  standpoint, 
and  the  risks  inherent  in  adding  communications  electronics  to  the 
existing  AEGIS  network  were  perceived  as  real. 

There  were,  however,  two  areas  related  to  the  AEGIS  combat 
system  where  analysis  showed  the  application  of  DMS  to  be  clearly 
beneficial.  First,  DMS  could  provide  a  needed  service  to  AEGIS  in 
distributing  Inertial  Navigation  Set  AN/WSN-5  data,  both  digital 
and  synchro,  to  the  various  users.  This  was  considered  a  valuable 
service  because  DMS  could: 

•  Convert  the  MIL-STD-1397A  Type  A  (NTDS  Parallel  Slow)  used  by 
the  AN/WSN-5S  into  a  Type  E  (Low  Level  Serial)  used  by  the  AEGIS 
computers , 

•  Provide  a  port  expansion  function  to  enable  a  single  AN/WSN-5 
digital  output  channel  to  provide  data  to  all  digital  users  of 
navigation  messages,  and 

•  Distribute  the  synchro  data  to  all  synchro  navigation  users, 
eliminating  the  need  for  large  switchboards  and  synchro  amplifiers. 

Secondly,  DMS  could  provide  a  backup  source  of  data  for  the 
Digital  Dead  Reckoning  Tracer  (DDRT) .  This  device,  a  plotting 
table  which  automatically  tracks  own  ship's  movements,  is  normally 
provided  with  inputs  from  the  Command  and  Decision  (C&D)  System 
computer.  To  increase  the  reliability  of  data  to  t..e  DDRT,  DMS 
processes  messages  from  the  two  Inertial  Navigation  Sets  (the  same 
messages  it  distributes  to  the  combat  system)  to  offer  two 
alternate  sources  of  inputs  for  the  DDRT,  identical  in  frequency 
and  format  to  the  existing  C&D  message,  should  the  C&D  computer  be 
off-line. 

The  lessons  learned  from  attempting  to  apply  data  busing  to  an 
existing  network  were  revealing: 

•  Although  weight  reduction  is  a  laudable  goal,  it  is  probably 
not  sufficient  reason  to  warrant  the  restructuring  of  an  existing, 
carefully  optimized,  digital  control  network. 

•  Where  data  busing  provides  a  clear  advantage  to  the  overall 
system  architecture,  its  introduction  occurs  smoothly,  even  when 
the  introduction  is  a  retrofit  into  an  existing  system. 
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6.  MACHINERY  CONTROL  SYSTEM 


Perhaps  the  first  surface  ship  control  system  whose 
architecture  evolved  into  a  network  optimized  around  a  general 
purpose  data  bus  is  the  DDG  51  Machinery  Control  System  (MCS) . 
During  Preliminary  Design,  high  level  drawings  were  already  showing 
digital  processors  controlling  or  monitoring  non-digital  devices, 
or  these  same  processors  communicating  with  each  other,  over  only 
two  redundant  interfaces  and  a  data  bus.  The  details  of  the 
implementation  and  documentation  of  such  a  system  were  not  worked 
out  yet,  but  the  computer  network  conceived  for  the  MCS  did  not 
consider  the  data  bus  as  an  add-on.  The  data  bus  was,  from  the 
start,  an  integral  part  of  the  architecture. 

By  the  end  of  Contract  Design,  much  of  the  MCS  network 
structure  and  some  of  the  communications  parameters  between  the  MCS 
processors  had  been  established.  For  example,  the  quantity  and 
location  of  each  of  the  MCS  processors  had  been  defined,  as  had 
been  a  good  portion  of  the  non-digital  sensors  and  controlled 
devices.  To  support  MCS  communications,  a  fairly  detailed  protocol 
to  be  Implemented  in  the  MCS  processors  had  been  worked  out. 

Soon  after  the  Detail  Design  phase  got  underway,  several 
aspects  of  the  MCS  network  which  had  previously  appeared  to  be  well 
established  were  suddenly  open  to  redesign.  The  flexibility  of  the 
bus  system  was  heavily  taxed  during  this  period.  The  following  are 
some  of  the  changes  which  had  significant  impact  on  use  of  the  data 
bus,  and  which  illustrate  the  need  for  flexibility  in  the  bus 
system: 


•  Change  to  Bridge  Control  Unit  -  Each  of  the  six  MCS  consoles 
had  been  assumed  to  Include  a  data  processor  -  an  AN/UYK-44  -  for 
data  processing  and  communications.  The  Bridge  Control  Unit,  which 
is  the  console  on  the  bridge  used  to  remotely  control  engines  and 
propellers,  was  redesigned  at  the  start  of  Detail  Design  to  become 
a  non-digital  peripheral.  What  had  been  two  redundant  NATO  STANAG 
4156  serial  digital  interfaces  became  almost  200  separate  discrete 
switch  closure,  discrete  logic  level,  and  synchro  interfaces  with 
DMS.  This  was  a  lesson  in  ensuring  that  generous  spare  capacity  be 
designed  into  a  data  bus  in  the  initial  design  phases.  What  had 
approached  50  percent  spare  capacity  in  this  area  of  the  ship 
suddenly  was  almost  totally  absorbed  by  this  one  change. 

•  Change  to  MCS  Message  Structure  -  The  original  intent  had  been 
that  the  MCS  processors  would  only  communicate  with  each  other  "by 
exception."  In  other  words,  if  all  parameters  stayed  unchanged  over 
a  particular  period  of  time,  no  communications  would  be  required. 
The  protocol  which  had  been  designed  during  Contract  Design  assumed 
this  approach,  and  was  therefore  quite  robust  but  also  cumbersome. 
It  was  decided  early  in  Detail  Design  that  too  many  parameters 
would  change  too  often  to  allow  such  a  structure  to  be  Implemented. 
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If  the  "by  exception"  design  were  to  be  used,  an  unacceptably  high 
ntinber  of  different  message  types  would  have  to  be  generated  each 
second  by  many  of  the  processors.  This  would  have  dedicated  too 
much  processor  time  to  the  communications  task.  Instead,  an 
asynchronous  and  periodic  communications  architecture  was  adopted 
whereby  each  console  would  send  status  updates  to  each  other 
console  two  times  per  second.  These  status  messages  were  to  be  very 
long,  up  to  1Kbyte  each. 

•  Change  to  MCS  Protocols  -  When  the  MCS  Interprocessor  messages 
and  the  messages  between  processors  and  non-digital  devices  are 
combined,  the  resulting  communications  load  was  such  that  the 
protocol  defined  during  Contract  Design  for  MCS  computers  was 
deemed  unacceptably  slow  and  prone  to  disruption.  As  a  result,  a 
more  streamlined  protocol  was  developed,  one  which  capitalizes  more 
effectively  on  the  connection-oriented  nature  of  DMS.  In  addition 
to  this,  the  message  error  checking  accomplished  within  the 
AN/UYK-44  processors  was  also  abbreviated  to  reduce  the  overall 
time  spent  in  communications. 

•  Future  MCS  Protocol  Modifications  -  A  network  of  computers 
which  only  communicates  "by  exception"  would  logically  adopt  a 
source  initiated  message  structure.  Since  the  MCS  computers  now 
communicate  periodically  rather  than  by  exception,  one  can  decide 
on  source  or  sink  initiation  of  messages  depending  on  which  is  most 
efficient.  (Note  that  this  topic  is  independent  of  DMS.  Even  if  the 
MCS  computers  were  hard-wired  together,  these  protocol  issues  would 
arise.  If  the  bus  system  can  efficiently  Implement  source  or  sink 
initiated  protocols,  which  DMS  can  do,  it  is  only  the  user 
application  which  determines  which  approach  is  best.)  Generically, 
with  or  without  a  bus,  to  reliably  transfer  source  initiated 
messages  between  two  computers  involves  four  steps: 

1.  Message  transfer  request  from  source  to  sink  device. 

2.  Sink  indicates  ready/not  ready  for  data. 

3.  Source  sends  data  when  sink  is  ready. 

4.  Sink  acknowledges  receipt  of  correct  message. 

Equally  reliable  sink  initiated  messages  only  involve  two  steps: 

1.  Message  request  from  sink  to  source. 

2.  When  ready,  source  sends  data. 

In  sink  initiated  transfers,  the  fact  that  the  requesting 
computer  receives  the  data  message  implicitly  means  that  the  other 
computer  was  available  and  that  the  message  transfer  occurred 
correctly. 

The  inherently  more  efficient  sink  initiated  protocols  are 
currently  being  tested  for  MCS  communications.  The  DMS  suite  used 
to  perform  these  tests  can  accommodate  either  source  or  sink 
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initiated  protocols  concurrently. 


Another  important  lesson  learned  in  the  application  of  DMS  for 
the  Machinery  Control  System  related  to  documentation.  The  MCS 
processors  Interface  with  many  hundreds  of  non-digital  devices  via 
DMS.  The  quantity  and  location  of  these  devices  is  often  not  under 
the  purview  of  the  Machinery  Control  System  MAVSEA  code.  Not  only 
did  the  MCS  community  not  know  what  all  of  these  peripherals  were, 
but  they  also  did  not  know  exactly  how  a  processor  connected  to  DMS 
would  read  or  control  these  devices.  Interface  Design 
Specifications  (IDS)  are  a  common  document  used  in  ship  design  to 
define  precisely  how  two  digital  processors  communicate,  but  IDSs 
had  not  been  needed  in  the  past  between  processors  and  non-digital 
peripherals.  To  meet  this  need,  a  system  was  designed  which 
automatically  provides  DMS  addresses  and  message  formats  for  all 
non-dlgltal  peripherals  connected  to  the  bus,  using  the  DDG  51 
Contract  Drawings  and  the  DDG  51  DMS  database  as  sources.  The 
document  and  floppy  disks  generated  are  used  by  the  MCS  community 
to  augment  their  MCS  IDS  and  allow  software  development  to  proceed. 
In  addition,  this  automatic  message  format  tool  allows  the  MCS 
software  to  keep  abreast  of  changes  that  occur  to  the  configuration 
of  these  non-digital  peripherals. 

7.  MCS  LAND  BASED  TEST/DEVELOPMENT  SITES 

Two  land  based  sites  have  been  established  to  develop  MCS  and 
to  test  the  MCS  operating  with  DMS:  the  MCS  Vendor  Test  Site  at  the 
General  Electric  Simulation  and  Control  Systems  Division  in  Daytona 
Beach,  and  the  Land  Based  Engineering  Site  (LBES)  at  the  Naval  Ship 
Systems  Engineering  Station  in  Philadelphia.  Both  of  these  sites 
are  provided  with  a  DMS  suite  which  is  considerably  smaller  than 
the  DDG  51  DMS,  but  Which  emulates  its  functionality.  Thus,  each 
MCS  processor  is  connected  redundantly  to  DMS  over  STANAG  4156 
serial  digital  Interfaces,  DMS  provides  redundant  data  paths 
between  terminals,  and  user  devices  related  to  MCS  which  are  not 
present  at  the  test  sites  are  emulated  by  simulation  computers. 

During  testing  at  these  sites,  a  number  of  problems  surfaced. 
Below  is  a  summary  of  problems  and  resolutions  related  to  the  non¬ 
trivial  system  level  issues  encountered. 

7.1  DMS  Problems  Found  at  MCS  Test  Sites 

Early  communications  testing  was  hampered  by  a  number  of  small 
but  disruptive  problems  in  the  DMS  terminal -to-user  device 
interface.  These  were  found  to  be  errors  in  execution  rather  than 
intrinsic  design  faults. 

a.  Unintentional  DMS  mode  enabled.  The  DMS  Specification  for 
the  STANAG  4156  interface  Includes  a  mode  called  the  "Type  B 
DMS-Inltiated  Source  Device  Transfer."  This  mode,  which  is  not 
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included  in  the  NATO  STANAG  4156  Specification,  is  not  understood 
by  the  AN/UYK-44's  STANAG  4156  interface  adapter.  DMS  was 
occasionally  enabling  this  mode  unintentionally,  and  the  result  was 
that  communications  with  the  particular  computer  port  would  be 
disrupted  for  periods  of  up  to  6  msec.  The  mode  was  disabled.  The 
lesson  is  that  when  Specifications  for  a  particular  system  impose 
requirements  beyond  those  stipulated  in  the  Standard,  extreme  care 
must  be  taken  to  ensure  that  complete  compatibility  is  maintained 
with  the  Standard,  in  all  operational  modes. 

b.  LBES  DMS  saturation.  Although  not  strictly  a  "DMS  problem" 
in  the  sense  the  others  are,  this  is  listed  under  DMS  because  it  is 
clearly  not  an  MCS  problem.  The  original  LBES  MCS  system  was  to 
consist  only  of  three  processors  communicating  over  DMS.  To  meet 
this  need,  a  small  DMS  was  designed  which  would  support  two 
simultaneous  intra-terminal  conversations  or  one  bus-mode 
conversation.  Later,  two  Integrated  Test  Sets  (ITS)  were  added  to 
the  MCS  processors  to  emulate  the  traffic  caused  by  the  three 
missing  consoles  and  by  some  of  the  non-digital  peripherals.  If 
the  three  actual  MCS  consoles  are  communicating,  DMS  supports  the 
message  traffic  properly.  If  the  two  ITSs  are  also  enabled  to 
respond  to  messages  but  not  to  initiate  their  own  traffic,  DMS 
still  supports  the  data  load.  However,  if  the  ITS  which  emulates 
the  three  missing  MCS  computers  is  set  to  emulate  more  than  one  of 
the  missing  consoles,  DMS  becomes  saturated.  The  symptom  is  that 
scheduled  messages  are  missed  at  a  rate  of  100  or  more  per  minute. 
To  resolve  this  problem,  the  LBES  DMS  was  upgraded  to  a  two  bus, 
two  (internally  redundant)  terminal  system  identical  to  the  MCS 
Vendor  Test  Site  configuration. 

c.  LBES  production  hardware  Turn-Around  Mode  problem.  When 
the  newest  production  STANAG  4156  interface  modules  were  installed 
in  the  two-bus  LBES  DMS,  the  turn-around  mode  (i.e.  when  data  are 
transferred  internally  rather  than  over  the  main  bus  cables,  used 
for  "local  calls")  was  found  to  be  unreliable.  The  bus  mode, 
however,  operated  correctly.  Older  STANAG  4156  modules  operated 
correctly  in  all  modes  with  the  new  DMS  equipment.  The  problem 
turned  out  to  be  caused  by  an  unfortunate  accumulation  of 
tolerances  between  the  new  DMS  terminals  and  the  new  STANAG  4156 
modules.  A  modification  to  the  terminals'  operating  program  and  to 
the  STANAG  4156  modules  corrected  the  problem.  This  demonstrates 
that,  especially  in  situations  involving  production  runs  which  are 
extended  over  long  periods  of  time,  it  is  important  to  strive  for 
the  lowest  possible  sensitivity  to  timing  tolerances.  If 
"equivalent"  components  from  different  manufacturers  will  be  used, 
or  even  components  taken  from  different  lots  produced  by  one 
manufacturer,  worst  case  combinations  of  timing  variability  must  be 
expected . 

It  should  be  noted  that  all  of  the  above  problems  related  only 
to  the  user-to-DMS  STANAG  4156  protocols  (including  protocols 
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between  DMS-user  interface  and  the  DMS  terminal) .  None  involved 
basic  DMS  protocols  or  timing.  As  might  be  expected,  the  Navy 
officer  and  GE  engineers  assigned  to  MCS  development  work  at 
Daytona  Beach  became  very  adept  at  detecting  and  correctly 
identifying  these  faults,  and  in  numerous  cases  these  same 
individuals  replaced  DMS  circuit  cards  or  PROMs  mounted  on  the 
circuit  cards  without  DMS  engineers  being  present.  NAVSSES 
personnel  have  become  equally  familiar  with  DMS. 

7.2  MCS  Problems  Found  at  MCS  Test  Sites 

In  spite  of  the  fact  that  the  above  DMS  problems  were  being 
resolved,  MCS  communications  were  still  not  meeting  expectations  at 
the  test  sites.  It  appeared  that  an  inordinate  number  of  messages 
were  being  transmitted  by  one  computer  but  not  acknowledged  by  the 
Intended  sink  computer.  The  details  of  what  was  modified^  to 
correct  each  of  the  problems  are  not  known  to  the  DMS  community, 
but  the  MCS-related  problems  can  be  roughly  organized  in  the 
following  categories. 

a.  "Periods  of  darkness".  After  an  MCS  processor  had  received 
a  message  via  DMS,  periods  of  time  in  excess  of  5  msec  were 
sometimes  measured  during  which  other  message  traffic  appearing  at 
the  Interface  (from  other  computers  in  the  MCS  network)  would  be 
"dropped  on  the  floor."  During  these  periods,  aptly  dubbed  "periods 
of  darkness"  by  the  NAVSEA  MCS  Project  Engineer,  the  interface 
appears  free  to  DMS,  so  the  protocol  adopted  for  MCS  communications 
allows  DMS  to  send  the  message  to  the  sink  interface.  The  sink 
device,  however,  could  not  process  the  incoming  message.  Several 
changes  to  the  MCS  software  were  implemented  which  reduced 
considerably  these  periods  of  darkness.  Among  the  changes  was  a 
more  efficient  message  checking  procedure,  such  that  conducting 
quality  checks  on  received  messages  would  not  preclude  processing 
other  message  traffic  to  as  large  an  extent. 

b.  Inefficient  interface  status  criterion.  The  original  MCS 
protocol  required  that,  should  an  interface  with  DMS  appear  to  be 
faulty,  the  MCS  console  associated  with  that  interface  would  send 
out  test  messages,  and  would  only  resume  communications  on  the 
interface  after  receiving  a  correct  test  message  response.  Very 
often,  however,  what  appears  to  be  a  faulty  interface  is  simply  a 
busy  interface,  which  clears  itself  in  due  course.  But  the  MCS 
user  protocol  caused  all  subsequent  messages  attempting  to  go 
through  the  interface  to  be  Ignored  unless  they  happened  to  be  test 
messages  responses.  So  the  initiating  processor  was  bombarding  that 
Interface  with  test  messages  to  other  devices,  attempting  to 
reestablish  the  DMS  port,  causing  a  bad  situation  to  become  worse. 
To  correct  this  problem,  the  MCS  software  was  changed  such  that  any 
correct  message  appearing  over  what  was  assumed  a  faulty  interface 
is  enough  to  consider  the  interface  fully  operational.  Thus, 
interfaces  are  typically  assumed  faulty  for  a  much  shorter  period 
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of  time,  good  messages  are  not  being  Ignored,  and  a  smaller 
quantity  of  test  message  traffic  is  generated. 


c.  ITS  not  ready  for  data  in  time.  The  original  protocol 
established  for  source-initiated  transfers  from  an  MCS  processor  to 
an  ITS  dictated  that  IMS  forward  the  request  header  to  the  ITS  to 
allow  it  to  prepare  itself  for  the  incoming  data  message.  Having 
forwarded  the  request  header  to  the  ITS,  DMS  would  then  immediately 
Indicate  to  the  source  MCS  computer  to  start  sending  the  data 
message.  Using  this  protocol,  DMS  would  send  the  first  data  word 
to  the  ITS  about  50  to  70  /isec  after  forwarding  the  request  header. 
This  was  not  allowing  the  ITS  enough  time  to  configure  itself  for 
the  incoming  message.  The  protocol  was  changed  such  that  the  DMS, 
having  forwarded  the  request  header  into  the  ITS,  must  now  wait  for 
the  ITS  to  acknowledge  when  it  is  ready  for  data.  This 
acknowledgement  is  then  used  by  DMS  to  indicate  to  the  source 
processor  that  it  can  start  sending  the  data  message. 

d.  Excessive  computer  response  time  to  Receive _ Pgqg^g.tS-  As 

mentioned  previously,  a  sink  initiated  intercomputer  protocol  is 
being  tested  at  the  MCS  Vendor  Test  Site.  To  alert  the  data  source 
computer  that  someone  has  requested  its  data  message,  DMS  forwards 
the  request  header  into  the  source  computer.  This  processor  then 
converts  its  input  buffer  into  an  output  buffer,  filling  the  output 
buffer  with  its  (long)  message,  then  sends  the  message  to  DMS. 
Very  often,  the  2  msec  DMS  waiting  time  was  being  exceeded,  and  the 
message  transfer  would  be  aborted.  To  solve  this  problem,  the  MCS 
processors  are  now  using  the  STAMAG  4156  Burst  Mode,  whereby  the 
processor  starts  sending  message  words  to  DNS  before  the  entire 
message  is  loaded  in  the  computer's  output  buffer. 

e.  Busy  signal  not  available  for  Receive  Requests.  (This  is 
not  strictly  an  MCS-related  problem,  it  is  actually  a  STANAG  4156 
shortcoming.  However,  the  solution  involves  the  MCS  processors,  so 
the  problem  is  described  here.)  STANAG  4156  does  not  specify  a 
"busy  signal"  during  Interprocessor  sink  initiated  transfers, 
although  such  a  signal  is  available  with  peripheral  device 
protocols.  As  is  the  case  for  source  initiated  transfers,  DNS 
could,  by  means  of  a  busy  signal,  indicate  to  a  requesting  computer 
within  3.4  msec  whether  or  not  the  requested  channel  can  be 
established.  If  the  AN/UYK-44  is  not  provided  with  this  signal, 
the  only  alternative  is  for  a  timeout  timer  to  be  set  within  the 
AN/UYK-44.  For  several  reasons,  in  this  application  this  timeout 
timer  cannot  be  less  than  20  msec,  which  means  that  16.6  msec  are 
wasted  whenever  DNS  cannot  establish  a  communications  channel.  It 
also  means  that  the  potential  for  message  disruptions  exists  during 
this  16.6  msec,  because  IMS  is  free  to  send  requests  to  the 
processor,  and  the  processor  is  still  waiting  for  DMS  to  honor  its 
previous  request  for  service.  One  solution  to  this  problem  is  that 
the  AN/UYK-44  must,  having  sent  its  request  header  to  DMS, 
temporarily  change  to  a  peripheral  sink  initiated  protocol.  When 
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DHS  senses  that  the  processor  Is  using  the  peripheral  protocol 
(STANAG  4156  Type  A) ,  It  will  provide,  as  necessary,  the  busy 
signal.  As  soon  as  the  data  message  or  the  busy  signal  have  been 
received  by  the  processor,  it  must  restore  the  intercomputer 
protocol . 

This  experience  with  the  two  MCS  test  sites  shows  clearly 
that,  especially  when  intercomputer  communications  are  Involved, 
testing  of  the  equipment  is  extremely  valuable.  When  large  systems 
are  Involved,  hard  to  detect  human  error  and  hard  to  predict  timing 
incompatibilities  are  bound  to  exist  and  must  be  systematically 
whittled  away.  In  spite  of  the  visibility  these  user  interface 
problems  received  at  different  periods,  in  retrospect  there  was 
nothing  intrinsically  wrong  with  the  MCS-DMS  system  design,  nor  was 
there  anything  particularly  surprising  about  the  nature  of  the 
problems  encountered. 

8.  STEERING  CONTROL  SYSTEM 

A  modern,  digital  computer-assisted.  Steering  Control  System 
is  designed  into  the  Arleigh  Burke  class.  This  highly  survivable 
control  system  Includes  an  autopilot,  a  fuel  conservation  node,  a 
ship  roll  reduction  mode,  and  several  backup  modes  of  operation 
should  the  steering  system  computer  fail  and  should  all  bus 
communications  fail. 

The  Steering  Control  System  (SCS) ,  like  the  MCS,  was  designed 
with  the  assumption  that  a  general  purpose  data  bus  would  be 
available,  although  a  less  capable  non-bus  variant  also  exists. 
The  SCS  consists  of  only  one  AN/UYK-44  processor,  located  in  the 
Steering  Gear  Room,  one  digital  peripheral  located  on  the  bridge, 
and  numerous  non-digital  devices  on  the  bridge  and  in  the  Steering 
Gear  Room.  The  AN/UYK-44  and  the  digital  peripheral  are  equipped 
with  serial  digital  STANAG  4156  interfaces.  Because  SCS 
incorporates  only  one  digital  processor  in  its  design,  the  message 
flow  turns  out  to  be  considerably  more  predictable  and  orderly  than 
the  asynchronous,  six-processor  MCS  network. 

The  SCS  evolved  much  like  the  MCS  during  the  DUG  51  contract 
Design  phase,  although  on  a  smaller  scale.  The  original  design 
included  primarily  digital  equipment  on  the  bridge,  a  processor  and 
non-dlgltal  devices  in  the  Steering  Gear  Room,  and  backup  steering 
cables  from  the  bridge  to  the  steering  room.  To  maintain  more 
similarity  between  the  DDG  51  SCS  and  the  non-bus  variant,  several 
functions  of  the  SCS  were  changed  from  digital  processor  functions 
to  contact  closure  discretes.  For  the  DDG  application,  these 
discrete  signals  are  sent  over  DMS  using  a  scheme  whereby  each  of 
the  two  rudders  is  serviced  by  redundant  paths  over  DMS. 

The  current  design  allows  steering  system  commands  to  be 
passed  to  the  AN/UYK-44  over  DHS,  steering  system  commands  to  be 
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transferred  between  non-digital  equipment  over  other  DMS  paths,  or 
rudder  commands  only  to  be  sent  over  the  backup  cables  between  the 
bridge  and  the  Steering  Gear  Room. 

The  steering  system's  AN/uyK-44  processor  was  always  intended 
to  provide  autopilot  operation,  but  the  details  of  the 
implementation  had  not  been  worked  out  at  the  beginning  of  Contract 
Design.  The  fuel  conservation  and  roll  reduction  modes  had  not 
been  included  originally.  Here  was  a  good  example  of  the  the  value 
added  to  a  system  design  by  the  existence  of  a  general  purpose  data 
bus. 


The  SCS,  from  the  start,  included  a  processor  redundantly 
connected  to  DMS.  The  SCS  designers,  when  faced  with  having  to 
implement  ah  autopilot  capability,  needed  to  accjuire  Own  Ship  Head 
from  the  Inertial  Mavigation  Sets.  How  best  to  accomplish  this? 
Because  the  SCS  computer  was  already  connected  to  DMS  via  STANAG 
4156  interfaces,  and  because  the  two  AN/WSN-5  navigators  were  also 
connected  to  DMS,  it  became  a  simple  matter  to  provide  the 
appropriate  addressing  information  to  the  SCS  processor,  and  have 
the  processor  request  Own  Ship  Head  from  either  AN/WSN-5  through 
the  redundant  STANAG  4156  interfaces.  Note  that  this  change  was 
limited  to  SCS  software  upgrade;  no  changes  to  DMS,  to  ship 
drawings,  or  to  cabling  were  required. 

When  the  SCS  was  upgraded  to  include  roll  reduction 
algorithms,  the  same  strategy  was  used.  The  AN/WSN-5s  provide  DMS 
with  Own  Ship  Roll  (OSR) ,  own  Ship  Pitch  (OSP) ,  and  the  North  and 
East  components  of  true  speed  (respectively  Vn  and  Ve)  in  addition 
to  Own  Ship  Head  from  their  synchro  outputs.  (The  AN/WSN-5S  also 
provide  many  other  parameters,  including  ship  position,  from 
digital  outputs.)  The  ship's  Electromagnetic  (EM)  Log  provides  DMS 
with  Own  Ship  Speed  (OSS)  through  the  water.  These  data  were 
provided  to  the  SCS  processor  by  incorporating  the  appropriate  DMS 
addresses  in  the  SCS  program.  Once  again,  with  no  changes  to  ship 
drawings  and  cabling,  roll  reduction  and  fuel  conservation 
algorithms  were  added  to  the  SCS  software. 

Since  the  steering  control  system  only  needs  OSH,  OSR,  Vn,  Ve, 
and  OSS  for  the  autopilot,  fuel  conservation,  and  roll  reduction 
functions,  DMS  converts  these  synchro  data  into  digital  messages 
and  sends  the  messages,  upon  request,  to  the  steering  processor 
over  the  STANAG  4156  interfaces.  The  advantage  of  using  the 
converted  synchro  rather  than  the  digital  AN/WSN-5  messages  is  that 
the  steering  processor  does  not  need  to  conform  to  the  AN/WSM-5s' 
message  timing;  the  processor  can  instead  request  these 
DMS-formatted  navigation  messages  at  any  time.  Message  formats  are 
documented  as  are  the  non-digital  peripheral  message  formats  for 
the  MCS.  Because  DMS  constructs  the  messages  "on  the  fly,"  data 
senescence  is  less  than  it  would  be  from  the  AH/WSN-5  digital 
messages  -  on  the  order  of  15  nsec  worst  case. 
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In  the  future,  more  functions  can  be  designed  into  the  SCS, 
still  with  no  change  to  cabling  or  drawings.  Ultimately,  for 
example,  the  steering  system  could  compute  the  best  routes  to  any 
point  on  the  globe  from  AN/WSN-5  ship  position  data  and 
geographical  data  stored  in  memory. 

The  operation  of  the  SCS  with  DMS  was  tested  in  a  full-up  DUG 
51  DMS  demonstration  at  the  Rockwell  International  Marine  Systems 
Division  plant  in  Anaheim,  California.  Only  one  problem  was 
discovered  of  a  non-trivial  nature:  a  condition  in  which  one  of  the 
redundant  halves  of  a  DMS  terminal  would  occasionally  not  service 
initiate  requests. 

This  problem,  referred  to  as  "RM  lockup,"  was  also  noticed  at 
the  Combat  Systems  test  site  in  Moorestown,  N.J.,  and  was  cured  by 
means  of  a  modification  to  the  operating  program  of  the  Remote 
Multiplexer  (the  Remote  Multiplexer,  RM,  is  the  DMS  terminal) .  The 
problem  was  found  to  occur  in  a  narrow  window  of  time,  if  a 
particular  terminal  were  to  receive  simultaneous  initiate  and 
response  mode  requests.  This  condition  had  not  been  noticed 
previously  because  situations  involving  very  high  retry  rates  are 
needed  to  cause  the  problem  to  occur.  Data  traffic  at  the  MCS  test 
sites  does  not  create  the  conditions  favorable  for  this  anomoly. 

9.  NAVIGATION  DATA  DISTRIBUTION  SYSTEM 

Much  about  the  distribution  and  conversion  of  navigation  data 
from  the  two  Inertial  Navigation  Sets  AN/WSN-5  has  already  been 
mentioned  in  previous  sections.  This  function,  which  includes 
distribution/conversion  of  both  synchro  and  digital  navigation 
data,  was  assigned  to  DMS  before  the  Contract  Design  phase  started. 
From  the  start,  an  unmutable  design  requirement  for  this  DMS 
application  was  that  introduction  of  DMS  cause  no  changes  to 
AN/WSN-5  or  combat  system  computer  software  or  interface  hardware. 

Originally,  the  AN/WSN-5  digital  messages  were  only  available 
in  an  Input/Output  configuration,  which  means  that  the  user 
computer  connected  to  each  digital  port  was  to  provide  control 
messages  to  the  navigation  set  on  a  constant  basis.  In  the 
original  implementation,  one  of  the  combat  system  computers 
connected  to  IMS  was  assigned  the  task  of  providing  the  AN/WSN-5 
control  messages.  The  others  would  receive  the  messages 
periodically  with  no  need  to  respond.  When  Output  Only  AN/WSN-5s 
became  available,  no  control  messages  from  the  combat  system 
computer,  via  DMS,  to  the  navigation  sets  were  required,  and  the 
appropriate  interfaces  were  deleted  from  the  design. 

DMS  distributes  navigation  data  to  combat  system  computers,  to 
certain  weapon  systems,  to  numerous  indicators  throughout  the  ship, 
to  certain  search  radar  systems,  to  the  Digital  Dead  Reckoning 
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Tracer,  and  to  the  Steering  Control  system.  In  addition  to  this, 
ms  includes  an  embedded  microprocessor  which  also  receives  the 
periodic  navigation  messages,  strips  out  the  Greenwich  Mean  Time 
words,  and  maintains  GMT  with  a  resolution  of  about  5  msec  for  any 
computer  user  of  ms.  The  embedded  microprocessor  includes  logic 
to  select  the  preferred  navigation  set  as  its  source  of  data.  This 
GMT  from  the  "ship's  master  clock"  is  currently  being  accessed  by 
the  Machinery  Control  System  computers,  and  is  a  requirement  of  the 
MCS  Specification. 

As  mentioned  previously,  DMS  provides  digital  navigation  data 
messages  to  the  combat  system  computers  via  MIL-STD-1397A  Type  E 
(or  Low  Level  Serial)  Interfaces,  while  the  AN/WSN-5  sends  the  data 
to  DMS  via  a  Type  A  parallel  interface.  This  involves  not  only  a 
conversion  in  interface  electrical  properties  and  bit  rate,  but 
also  changes  to  handshake  protocols  and  word  length.  The  DMS 
implementation  of  this  conversion  function  is  such  that  the  message 
formats  for  the  converted  LLS  messages  are  identical  to  those 
prescribed  for  the  future  LLS  AM/WSM-Ss.  However,  certain  details 
of  the  DMS-to-computer  LI£  interface  timing  are  not  identical  to 
the  expected  LLS  AN/HSN-5  to  user  timing.  For  example,  the 
AN/WSN-5  is  expected  to  offer  the  message  to  the  user,  then  retry 
one  time,  10.24  msec  later,  should  the  user  be  unable  to  receive 
the  message  on  the  first  attempt.  Since  the  AN/WSN-5  and  the  users 
are  essentially  isolated  by  DMS,  this  retry  at  10.24  msec  becomes 
meaningless.  Instead,  DMS  will  allow  the  user  devices  up  to  4  msec 
to  accept  data  or  command  interrupt  messages.  Should  a  user  not 
accept  the  message,  DMS  will  discard  those  data  and  provide  the 
next  message  update  on  schedule. 

These  differences  between  the  DMS  LLS  navigation  messages  and 
the  future  AN/WSM-5  LLS  navigation  messages  meant  that  an  Interface 
Design  Specification  tailored  to  the  DMS  interface  was  needed. 
This  DDG  51  digital  navigation  data  distribution  IDS  also 
identifies  which  of  the  numerous  AN/WSN-5  options  were  selected  for 
use  in  the  DDG  51  application. 

The  MIL-STD-1397A  Type  E  interface  was  designed  with  numerous 
System  Integrity  Features  (SIF)  to  permit  constant  monitoring  of 
interface  status  by  the  connected  devices.  Among  these  are 
continuous  "keep  alive"  signals  and  optional  parity  checks.  The 
DNS  Type  E  Interface  card  Includes  error  messages  or  Command 
Interrupt  Words  to  Inform  user  devices  of  any  errors  detected  by 
DMS  in  a  message  transfer.  In  the  Initial  enthusiasm  for  this  new 
interface  standard,  the  design  was  to  include  use  of  most  of  the 
SIFs  between  DNS  and  combat  system  computers.  However,  it  soon 
became  evident  to  the  combat  system  software  designers  that  using 
all  of  the  SIFs  would  involve  a  considerable  software  effort.  Most 
of  these  features  were  eventually  dropped  from  the  requirements. 
The  changes  to  Mis,  as  specific  SIFs  were  selected  and  deselected, 
were  limited  to  coding  of  a  PROM  at  each  of  the  interface  cards. 
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10.  NAVIGATION  DATA  DISTRIBUTION  TESTING 


The  Combat  System  Engineering  Development  Site  (CSEDS)  in 
Moorestown,  N.J.  is  provided  with  a  three-bus  DMS  for  the  purposes 
of  testing  many  of  the  combat  system  interfaces  with  DMS.  Among 
these  are  the  two  AN/WSN-5  sources  (one  of  them  a  simulator) , 
numerous  synchro  navigation  data  sources  and  sinks,  antenna  bearing 
signals,  and  wind  speed  and  direction.  To  emulate  other  signal 
traffic  in  the  DDG  51  DMS,  the  CSEDS  DMS  is  also  provided  with 
selectable  background  data  load  in  four  stages:  no  extra  load,  a 
DDG  51  equivalent  load,  and  two  overload  levels  to  stress  DMS 
beyond  the  DDG  51  traffic  load.  These  extra  DMS  messages  are 
created  by  remotely  enabling  PROMs  which  send  data  through  the  bus 
between  actual  source  devices  and  unused  sink  interface  channels. 
The  maximum  load  is  designed  to  be  approximately  the  highest 
message  update  rate  which  the  DMS  at  the  site  can  service.  Some  of 
the  problems  and  resolutions  encountered  at  this  site  have  been: 

a.  Occasional  loss  of  End  Of  Message  External  Function.  Each 
digital  message  from  the  AN/WSN-5S  actually  consists  of  three 
messages:  two  External  Functions  (EF)  and  the  data  message.  The 
AN/WSN-5  first  transmits  a  one-word  Start  of  Message  (SOM)  EF,  then 
a  variable  length  data  message,  and  finally  a  one-word  End  of 
Message  (EOM)  EF.  The  End  of  Message  EF  appears  while  DMS  is  still 
busy  distributing  the  data  message  to  the  combat  system  computers. 
At  times,  the  EOM  attempting  to  reach  the  message  distribution 
processor  within  DMS  during  this  busy  period  just  does  not  succeed. 
This  problem  was  addressed  by  means  of  adjusting  the  internal  DMS 
retry  parameters.  EOMs  are  currently  lost  at  the  rate  of  about  one 
per  hour.  Another  approach  for  resolving  this  issue  would  be  to 
program  DMS  to  ignore  the  EFs  from  the  AN/WSN-5s,  and  Instead  to 
generate  its  own  EFs  based  upon  the  arrival  of  data  messages.  This 
approach,  under  consideration  at  this  time,  should  noticeably 
increase  the  digital  navigation  message  success  rate. 

b.  RM  lockup.  As  described  in  the  steering  control  section, 
the  DMS  terminals  associated  with  the  AN/WSN-5S,  the  ones  with  the 
numerous  retries,  occasionally  were  locked  out  of  initiate  mode.  An 
update  of  the  operating  program  resolved  this  problem. 

c.  Synchro  instability.  When  I»!S  is  connected  to  synchro 
repeaters,  the  internal  DMS  digital  angle  value  is  converted  to  a 
synchro  value  by  means  of  digital-to-synchro  (D/S)  converters.  In 
some  cases,  the  synchro  signal  provided  by  DMS  becomes  unstable  in 
certain  quadrants.  It  turns  out  that  some  D/S  converters, 
particularly  those  of  commercial  grade,  become  unstable  if  the  load 
includes  a  significant  amount  of  capacitance,  such  as  would  be 
encountered  with  long  Interface  cable  runs.  Since  the  problem  only 
occurs  with  certain  brands  of  D/S  converters,  those  brands  could  be 
avoided.  Another  solution,  not  sensitive  to  converter  brand,  is  to 
Include  a  series  resistor  at  each  synchro  interface. 


3.113 


11.  IC  ALASHS  AND  INDICATORS 

In  addition  to  combat,  machinery,  steering,  and  navigation 
systems,  DMS  services  a  host  of  other  DDG  51  Interior 
Communications  (IC)  signals.  These  include  the  wind  data 
distribution  system,  rudder  angle  indicators,  various  door  alarms, 
dew  point  alarms,  fuel  system  alarms,  the  Collective  Protective 
System  alarms,  and  many  other  such  signals.  Many  of  these  DMS 
communication  links  are  between  sensors  and  non-digital  indicators 
or  indicator  panels.  DMS  in  these  applications  was  introduced 
primarily  because  it  is  well  suited  to  select  alternate  redundant 
data  sources,  and  multicast  the  data  to  numerous  sink  devices. 
Another  reason  for  connecting  some  of  these  signals  to  DMS  is  to 
make  them  available  to  the  Machinery  Control  System  computers,  over 
their  STANAG  4156  digital  interfaces.  Again,  the  architecture  of 
the  IC  system  communicating  over  a  general  purpose  data  bus  offered 
an  overall  performance  benefit. 

Issues  involved  in  the  application  of  DMS  to  the  IC  alarms  are 
typically  less  complex  than  the  ones  described  previously  because 
most  of  these  are  signals  between  non-digital  devices.  DMS 
provides  message  timing  and  signal  conversion.  Verification  of 
correct  message  flow  for  the  "dumb  to  dumb"  device  signals  was 
accomplished  on  the  DDG  51  DMS  shipset  during  the  DDG  51  DMS 
demonstration. 

12 .  SUMMARY 

Application  of  the  DMS  general  purpose  bus  to  the  DDG  51  Class 
has  illustrated  the  following  general  concepts: 

•  Cable  and  cost  savings  are  only  preliminary  goals  of  data 
busing,  and  are  not  enough  by  themselves  to  justify  use  of  a  data 
bus  system  in  a  shipbuilding  program.  A  fundamental  understanding 
of  system  performance  enhancements  or,  better,  systems  designed  to 
operate  with  a  data  bus  are  needed  to  ensure  that  the  bus  be  used 
to  its  potential. 

•  To  extract  the  full  potential  from  a  data  bus  application  in 
modern  surface  combatants,  the  application  cannot  be  viewed  merely 
as  replacement  for  point-to-point  cable.  It  is  doubtful  whether  a 
data  bus  applied  in  this  manner  could  ever  result  in  an  overall 
improvement  over  hardwired  methods  of  communication.  A  data  bus 
application  must  be  considered  at  a  whole  system  architecture 
level. 


•  The  isolation  provided  by  a  general  purpose  data  bus  between 
user  devices,  and  between  the  core  bus  structure  and  user  devices, 
is  a  desirable  attribute  to  ensure  long  term  system  compatibility. 
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•  The  DDG  51  experience  has  shown  that  virtually  all  of  the 
technical  problems  encountered  involved  the  user-to-bus  terminal 
interface  rather  than  internal  bus  system  problems.  Whether  the 
goal  is  to  achieve  a  prescribed  level  of  performance,  to  correct  an 
unforeseen  problem,  or  to  add  communications  modes  in  support  of 
new  user  system  features,  flexibility  in  the  user-to-bus  interface 
is  an  important  asset  of  the  general  purpose  bus  system. 

•  System  level  testing  is  extremely  valuable.  As  the  adage  says, 
"You  don't  know  what  you  don't  know."  The  potential  for  problems  is 
significant  when  so  many  different  systems,  developed  by  diverse 
activities,  are  connected  together.  It  is  much  easier  to  find  and 
correct  problems  in  a  laboratory  environment  than  on  board  ship 
during  construction. 

•  Maintaining  configuration  control,  in  a  large  general  purpose 
bus  application  such  as  the  DDG  51  DMS,  is  a  demanding  and 
critically  important  endeavor.  To  track  the  constant  changes 
occurring  in  a  ship  design,  and  their  impact  on  the  data  bus, 
requires  the  use  of  sophisticated  database  techniques. 

13.  THE  FUTURE 


In  the  introduction  it  was  mentioned  that  the  bus  system  must 
be  capable  of  supporting  user  interface  upgrades  as  well  as 
upgrades  to  its  own  capabilities.  It  is  clear  that,  as  message 
volume  and  data  rate  requirements  increase,  eventually  changes  to 
the  bus  are  needed  as  existing  spare  capacity  becomes  exhausted. 


One  advantage  of  a  general  purpose  data  bus  is  that  the 
isolation  between  the  bus-user  protocols  and  the  internal  bus 
protocols  allows  upgrades  to  either  to  be  accomplished 
"transparently."  For  example,  should  a  new  user  interface  be 
introduced,  neither  the  bus  system  nor  other  existing  user  devices 
need  be  affected.  Similarly,  should  a  new,  faster  main  bus 
architecture  be  introduced,  perhaps  to  allow  more  effective 
servicing  of  new  user  types,  the  other  devices  connected  to  the  bus 
need  not  be  affected. 


There  are  plans  underway  at  this  time  to  upgrade  the  main  DMS 
bus  architecture  to  Increase  the  maximum  system  data  rate  from  the 
current  gross  of  24  Mbps  to  lOO  Mbps  or  more.  The  plan  is  to 
convert  the  existing  DMS  coaxial,  linear  main  bus  cable  structure 
into  a  dual  token-passing  ring  Fiber  Distributed  Data  Interface 
(FDDI)  architecture.  The  FDDI  approach  involves  the  following 
modifications  to  the  existing  DMS: 

a.  Each  lOU  is  changed  to  interface  with  two  FDDI  ring  pairs 
instead  of  the  current  Remote  and  Area  Multiplexers, 

b.  For  existing  user  devices  which  depend  on  a  connection- 
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oriented  protocol,  the  FDD!  lOUs  convert  the  user  protocol  to  the 
connectionless,  source-initiated  scheme  needed  for  communicating 
over  the  FDD!  medltua, 

c.  The  existing  DOG  51  DMS  user  devices  must  notice  no  change 
in  service.  This  Includes  maintaining  all  critical  timing 
parameters  as  they  are  now,  maintaining  message  structures  as 
specified  in  the  current  DMS,  and,  to  the  extent  possible, 
maintaining  the  same  physical  connection  between  existing  users  and 
the  Input  Output  Units. 

d.  Future,  faster  users  must  be  capable  of  taking  advantage 
of  the  faster  channel  data  rate  offered  by  the  PDDI  medium. 

Thus,  the  FDDI  upgrade  plan  consists  of  developing  an  emerging 
commercial  ring  bus  standard,  PDDI,  into  a  general  purpose, 
militarized  data  bus  system  which  would  transparently  upgrade  the 
current  DMS. 

A  future  refinement  of  this  upgrade  could  be  to  pursue  the 
same  general  course  as  described  above,  but  to  replace  the  FDDI 
medium  with  emerging,  faster  media.  This  would  allow  the  upgraded 
DMS  to  maintain  service  unaltered  for  existing  user  devices,  but 
would  also  support  faster  devices,  such  as  equipment  with  video  and 
voice  interfaces. 

Irrespective  of  the  specific  bus  medium  used,  the  objective 
will  always  be,  when  upgrading  individual  systems  for  surface 
combatants,  to  remain  compatible  with  current  equipment.  The  next 
decade  will  doubtless  bring  significant  advances  to  busing 
technology,  greatly  surpassing  FDDI,  so  it  is  imperative  for  any 
standard  Navy  general  purpose  bus  to  remain  flexible  and  compatible 
with  numerous  different  technologies. 
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14.  APPENDIX:  OSI  PROTOCOL  LAVERS  AND  GENERAL  PURPOSE  BUSES 


This  brief  introductory  discussion  of  the  relationship  between 
general  purpose  data  bus  systems  and  communication  protocol  layers 
is  intended  to  facilitate  the  understanding  of  how  the  Data 
Multiplex  System  AN/USQ-82 (V)  was  applied  to  DDG  51,  and  to  more 
clearly  categorize  the  nature  of  problems  encountered  in  this 
application. 

The  International  Standards  Organization  (ISO)  has  developed  a 
model  to  describe  generically  the  different  layers  of  protocols 
which  digital  devices  must  implement  to  communicate.  The  model, 
referred  to  as  the  Open  System  Interconnection  (OSI)  Reference 
Model,  is  intended  primarily  to  provide  a  framework  for 
understanding  the  communications  process;  OSI  does  not  specify  how 
each  layer  of  protocol  must  be  conducted. 


The  OSI  model  organizes  the  steps  taken  by  users  to 
communicate  into  seven  categories  or  layers,  the  lowest  level  being 
the  physical  connection  medium,  and  the  highest  being  the  interface 
with  a  processor's  application  programs.  A  very  brief  description 
of  each  of  the  layers  follows: 


Open  System  Interconnection  (OSI)  Model 
_ Protocol  Lavers _ 


Laver  Name 


Protocol  Function 


1.  Physical 

2.  Data  Link 

3 .  Network 

4 .  Transport 

5.  Session 

6.  Presentation- 

7.  Application  - 


Mechanical,  electrical  interface  medium. 

Data  formatting,  data  routing  scheme. 

Message  formatting,  segmenting,  addressing. 
End-to-end  error  correct,  routing  to  Appl . Progrms . 
Structuring,  organizing  of  communications. 
Translation  of  data  presentation  schemes. 

Interface  to  Application  Programs. 


If  two  computers  are  hardwired  together,  then  all  of  the 
protocol  layers  would  be  conducted  by  the  computers  themselves, 
since  no  other  entity  would  exist  to  carry  out  these  functions.  On 
the  other  hand,  addressing  of  messages  between  physical  connection 
points  would  be  fairly  trivial,  since  a  hardwired  connection  only 
ties  two  points  together.  A  message  being  transmitted  by  a 
particular  channel  of  computer  A  would  always  appear  at  the  same 
channel  of  computer  B. 


A  bus  system  between  the  two  computers  would  dictate  that 
certain  specific  standards  be  adhered  to  in  order  that  computers 
and  bus  operate  together.  A  general  purpose  bus  is  a  system  which 
allows  computers  with  various  Interface  types,  or  even  non-digital 
devices,  to  use  the  bus  for  communications. 
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The  Data  Multiplex  System  AN/USQ-82(V)  is  a  general  purpose 
bus  system  which  operates  from  the  OSI  Physical  through  much  of  the 
Network  Layer.  Higher  levels  of  protocol  are  left  to  the  user 
processors.  There  are  several  areas  in  which  general  purpose  buses 
such  as  DMS  differ  from  the  more  common  applications  of  the  OSI 
concept  to  data  busing: 

•  Interfaces  between  users  and  bus  system  can  be  any  of  a  list 
of  Navy  standard  digital  or  non-digital  types.  DMS  is  designed  to 
provide  physical  and  protocol  conversion  functions  such  that 
subscribers  communicating  over  DMS  need  not  conform  to  one 
particular  standard.  (Internally,  DMS  uses  a  connection-oriented 
protocol  which  supports  periodic,  aperiodic,  source  initiated,  or 
sink  initiated  message  transfers.  Access  to  the  multiple  main 
buses  is  achieved  via  a  polling  scheme  from  bus  controllers  to 
terminals,  and  via  a  prioritized  queue  contention  scheme  between 
user  devices  and  terminals.) 

•  DMS  can  be  set  up  to  allow  a  user  device  to  format,  schedule, 
and  address  its  own  messages  or  DMS  can  provide  some  or  all  of 
these  services.  How  much  of  the  inherent  bus  system's  flexibility 
a  subscriber  takes  advantage  of  depends  on  how  much  bus 
control -related  software  the  subscriber  develops.  A  computer 
application  which  was  formerly  hardwired  may  opt  not  to  change  any 
aspect  of  its  software  if  the  bus  control  features  are  not 
required. 

•  Since  the  bus  system  must  convert  user  signals  to  its  own 
standard  at  the  source  end,  there  is  no  reason  why  it  cannot 
provide  the  signal  to  the  sink  device  using  a  different  interface 
format.  In  fact,  just  as  the  physical  interface  at  each  end  of  the 
link  can  differ,  so  too  can  the  user-to-bus  system  protocols. 

Figure  1  shows  the  physical  connection  between  two  processors 
using  DMS  and,  by  means  of  the  familiar  OSI  protocol  stacks.  Figure 
2  is  the  representation  of  an  example  of  the  protocol  interactions. 
The  example  shows  a  serial  digital  STANAG  4156  processor 
communicating  with  a  parallel  MIL-STD-1397A  Type  A  computer.  In 
the  example,  the  STANAG  4156  computer  is  dynamically  changing 
message  routing  through  DMS  by  acting  directly  at  the  DMS  Network 
Layer.  The  MIL-STD-1397A  computer  is  connected  as  if  hardwired. 
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Notes: 

1.  The  dotted  arrow  between  the  source  user  and  the  DMS  Network 
Layers  '  'icates  that  the  source  user  device  is  acting  directly  on 
DMS  me  addi  ing.  The  sink  device  in  the  example  is  not 
aware  oi  ns  .n  message  routing. 

2.  RMs  conduct  DMS  and  user  addressing  functions,  message 
formatting,  message  timing.  AMs  route  messages  through  first 
available  of  20  data  channels  on  the  5  main  bus  cables. 

Figure  2.  OSI  Protocol  Layer  Representation  of  Two 
Computers  Communicating  via  DMS 
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1.  ABSTRACT 

The  planned  introduction  of  digital  control  systems  for  RN 
warship  machinery  control  and  surveillance  led  to  the  requirement  for 
Independent  assessment  of  their  performance,  prior  to  ship  trials. 

This  paper  describes  the  computer-based  Assessment  Facility, 
established  at  the  Admiralty  Research  Establishment  West  Drayton, 
which  performed  this  task  for  the  Type  23  Frigate.  It  discusses  the 
reasons  for  the  significant  cost  of  such  a  facility  but  demonstrates, 
through  consideration  of  indirect  as  well  as  direct  benefits,  the 
value  of  such  an  approach  and  concludes  that  a  policy  of  independent 
assessment  should  be  retained. 

2.  INTRODUCTION 

The  first  Type  23  Frigate,  H.M.S.  Norfolk,  was  accepted  by  the 
Royal  Navy  from  the  shipbuilder  in  November  1989.  She  has  the  first 
digital  computer-based  Machinery  Control  And  Surveillance  (MCAS) 
system  for  a  RN  warship.  At  the  time  this  type  of  control  system  was 
selected  an  immediate  concern  was  the  question  of  proving  its 
operation  and  reliability  before  sea  trials. 

It  was  agreed  that  the  Admiralty  Research  Establishment  ,  West 
Drayton  (ARE  (WD) )  would  produce  a  computer-based  machinery  simulator 
to  which  a  production  set  of  MCAS  equipment  would  be  connected  and 
undergo  thorough  assessment  in  support  of  the  acceptance  programme 
for  the  MCAS  design.  The  simulator  and  associated  environment  is 
known  as  the  Assessment  Facility.  It  was  produced  during  the  period 
1985-1989. 

This  paper  firstly  describes  the  Type  23  MCAS  system  and  its 
boundaries.  It  then  describes  the  structure  of  the  Assessment 
Facility  and  some  of  the  lessons  learnt  during  its  development.  This 
is  followed  by  an  outline  of  some  of  the  MCAS  trials  that  were 
performed  using  this  facility,  and  a  description  of  how  the 
existence  of  this  test  environment  led  to  ideas  for  future  MCAS 
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developments  which  could  be  investigated  with  minimal  recourse  to  the 
manufacturer  and  without  affecting  any  ship  timetable. 

The  paper  finally  demonstrates  how  an  agreed  plan  for  a 
through-life  assessment  facility  could  have  large  benefits,  which 
would  be  maximised  if  some  degree  of  independence  is  retained. 

3.  THE  TYPE  23  FRIGATE  MACHINERY  FIT 

The  Ship  Control  Centre  (SCC)  for  the  Type  23  provides  control 
and  monitoring  of  the  propulsion,  electrical  generation  and 
distribution,  and  auxiliary  systems. 

The  propulsion  system  consists  of  two  shafts  each  driving  a 
fixed  pitch  propeller.  The  drive  configuration  for  each  shaft  is 
CODLAG  with  a  gas  turbine  driving  through  a  gearbox,  via  a  Self 
Shifting  and  Synchronising  clutch,  and  a  direct  drive  electric  motor 
providing  cruise  and  astern  drive.  The  electrical  systems  comprise  4 
600V  diesel  generators  which  provide  the  electrical  power  for  the 
propulsion  electric  motors  and  drive  the  440V  motor/generator  sets 
for  ship  service  loads.  The  auxiliary  systems  are  listed  in  Table  1. 


TABLE  1.  Auxiliary  Machinery  Systems. 
Fuel  supply,  transfer  and  renovation  system. 


Lubricating  oil  supply,  transfer 
Chilled  water  system  (3  off) 
Ventilation  system. 

High  pressure  air  system. 

Low  pressure  salt  water  system. 
Aviation  fuel  system. 

Steering  system. 

Fresh  water  system. 

Bilge  and  sullage  system. 


and  renovation  system. 
Refrigeration  system. 

LOW  pressure  air  system. 

Special  services  air  system. 

High  Pressure  salt  water  system. 
Desalination  system. 

Stabilizer  system. 

Sewage  system. 


4.  THE  TYPE  23  FRIGATE  MACHINERY  CONTROL  AND  SURVEILLANCE  SYSTEM 

Vosper  Thornycroft  Controls  (VTC)  was  contracted  to  produce  the 
SCC  consoles  (encompassing  remote  control  and  primary  surveillance  of 
the  machinery  systems),  local  plant  controllers  for  the  diesel 
generators  and  chilled  water  plants,  and  a  secondary  surveillance 
facility.  For  the  purposes  of  this  paper  these  items  will  be 
regarded  as  forming  the  Type  23  MCAS. 

The  Type  23  MCAS  is  a  distributed  digital  system  based  around 
'D86'  hardware.  Each  d86  unit  contains  a  standard  bac)cplane  into 
which  a  range  of  double  euro-card  height  pcb  assemblies  are  inserted. 
This  range  comprises  processor  (Intel  8086),  memory,  interface,  and 
communications  cards.  There  are  a  total  of  17  d86  units  utilised  in 
the  Type  23  MCAS,  5  being  installed  in  the  SCC,  and  12  distributed 
throughout  the  ship  as  shown  in  Figure  1. 
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Figure  2.  D86  based  units  connected  by  serial  data  links. 


V 


Each  Local  Control  Panel  (LCP)  consists  of  an  operator  panel  and 
086  unit  which  provides  sequential  control  of  starting  and  stopping, 
primary  surveillance  and  data  collection  functions  for  that  machinery 
item  (diesel  generator  or  chilled  water  plant). 

The  Control  and  Data  Collection  Units  (CDCUs)  for  the  Gas 
Turbines  and  Electric  Motors  consist  of  086  units  which  accept  power 
demands  from  the  operator  at  the  SCC  and  schedule  power  between  the 
prime  movers,  transferring  the  resultant  signals  to  the  local  Plant 
Control  Unit  (PCU).  These  PCUs  provide  reversionary  control 
positions  and  contain  analogue  electronics  performing  governor-type 
functions.  They  do  not  contain  086  units,  the  CDCUs  collect  data 
from  the  prime  movers. 

Data  collection  from  auxiliary  machinery  is  performed  by  data 
collection  units  (DCUs),  one  of  which  is  housed  in  a  machinery  space 
while  the  others  are  housed  within  the  SCC.  The  LCPs,  CDCUs  and  DCUs 
are  all  connected,  by  individual  serial  data  lin)cs,  to  a  D86-based 
communications  sub-system  housed  in  the  SCC.  These  links  form  a 
'star'  network  with  the  communication  sub-system  at  the  hub.  Figure  2 
shows  the  interconnection  of  the  D86-based  units. 

Although  the  Type  23  HCAS  is  correctly  described  as  a 
distributed  digital  system  the  control  system  is  essentially 
hardwired.  State-demand  signals  are  wired  directly  from  the  SCC 
switches  to  the  local  D86  unit  or  on-plant  actuators.  value-demand 
signals  (lever  position)  are  wired  directly  to  the  CDCUs.  Parameters 
displayed  on  the  SCC  consoles  are  hard-wired  directly  from  the 
outputs  of  the  local  d66  units  or  from  on-plant  sensors.  Alarm 
conditions  recognised  by  on-plant  sensors  are  wired  directly  to  a 
D86-based  alarms  sub-system,  housed  in  the  SCC,  which  drives  the 
relevant  SCC  displays.  Warning  conditions  recognised  by  local  D86 
units  are  wired  directly  to  the  SCC  displays. 

Hence  control  and  primary  surveillance  does  not  use  computer 
communications.  The  serial  data  links  are  used  to  carry  secondary 
surveillance  information.  This  consists  of  transduced  plant  values 
collected  on  a  cyclic  basis  and  warning  conditions  deduced  from  these 
values.  Thus  the  warning  conditions  are  hardwired  to  the  SCC  for 
primary  surveillance  purposes  and  communicated  to  the  secondary 
surveillance  system. 

The  secondary  surveillance  hardware  brings  about  2200  parameters 
to  the  communications  sub-system  in  the  SCC.  There  are  2  plasma  panel 
visual  display  units  (VDUs)  in  the  SCC,  one  in  the  Supervisor's 
console  and  one  in  the  power  distribution  console.  These  can  be  used 
independently.  There  are  2  printers,  the  Event  Printer  and  the  Log 
Printer,  both  use  dot-matrix  technology.  The  printers  and  VDUs  are 
connected  to  a  D86-baBed  secondary  surveillance  sub-system  which  is 
connected  to  the  communications  sub-system  by  a  serial  data  link. 

Secondary  surveillance  facilities  include: 
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*  Automatic  printing  of  telegraph  movements,  warning  and 

alarm  conditions. 

*  Parameter  monitoring  and  trend  display. 

*  Request  printing  of  watch  changeover  logs  and  log  sheets. 

5.  ROLE  OF  ASSESSMENT 

It  was  agreed  that  an  early  production  set  of  HCAS  equipment, 
together  with  associated  documentation,  would  be  supplied  to 
ARE  (WD). 

Hence  the  assessment  role  required  funding  to  divert  this 
equipment  to  ARE  (WD),  to  provide  engineering  staff  from  VTC  to  help 
set  the  equipment  to  work,  and  to  cover  the  cost  of  refurbishment 
when  that  set  was  returned  for  subsequent  ship  fitting.  The  outright 
purchase  of  a  set  of  MCAS  equipment  for  the  Assessment  Facility  was 
not  considered  to  be  cost-effective. 

The  high-level  objectives  of  the  assessment  process  were: 

*  Assess  all  aspects  of  the  system  as  fit  for  purpose. 

*  Identify  any  shortcomings  in  the  system  including  those 
affecting  the  system's  ability  to  meet  the  Statement 
of  Technical  Requirements  (STR). 

*  Assess  diagnostic  and  maintenance  facilities. 

*  Assess  the  system  documentation. 

*  Investigate  the  operability  of  the  system  under  normal  and 
abnormal  conditions. 

These  objectives  were  to  be  achieved  by  a  combination  of 
documentation  review,  equipment  trials,  and  ergonomic  studies. 

Two  bodies,  the  Executive  Trials  Authority  (ETA)  and  the  Joint 
Trials  Team  (JTT)  were  established  to  oversee  the  assessment  process. 

The  ETA  was  solely  comprised  of  Ministry  of  Defence  (MOD) 
representatives.  It  co-ordinated  all  aspects  of  the  policy  of 
assessment  from  the  scope,  delivery  and  procurement  of  equipment  to 
be  assessed,  through  the  definition  of  the  trials'  objectives  and 
approval  of  the  trials'  programme,  to  consideration  of  actions  to  be 
taken  based  upon  trials'  results. 

The  JTT  comprised  representatives  from  MOD  and  from  the  control 
system  and  machinery  sub-contractors.  Its  role  was  to  provide 
technical  information  to  define  the  simulator  performance 
requirements,  and  to  plan,  produce,  execute  and  review  the  trials' 
procedures  and  results.  The  JTT  considered  any  risks  contained  in 
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proposed  trials,  JTT  agreement  o£  such  trials  denoting  the  acceptance 
of  any  risk. 

The  stages  through  which  equipment  trials  passed  were: 

a)  Proposal  for  trial,  and  JTT  agreement. 

b)  Production  of  trial  schedule,  and  JTT  agrement. 

c)  ETA  approval,  and  incorporation  into  the  trials  programme. 

d)  Execution  of  trial,  with  simultaneous  report  preparation. 

e)  Comment  by  JTT. 

f)  Issue  of  report. 

The  Conducting  Authority  for  the  trials  was  ARE  (WD) . 

6.  THE  ASSESSMENT  FACILITY 

The  Assessment  Facility  was  required  to  simulate  the 
characteristics  of  the  Type  23  machinery  systems  and  to  connect  to  a 
production  set  of  MCAS  equipment.  The  first  problem  lay  in  defining 
the  simulator  boundaries. 

6.1  Simulator  boundaries. 

The  Main  Electrical  Power  System  (HEPS)  controls  the  generation 
and  distribution  of  electrical  power  for  both  the  600  and  440  volt 
systems,  and  provides  automatic  parallelling  of  the  diesel  generators 
onto  the  600  volt  buses.  It  consists  of  a  Primary  Electrical  Control 
Panel  (PECP)  in  the  SCC  which  contains  a  D86  unit  that  is  connected, 
by  serial  data  links,  to  2  further  D86  units  housed  in  Secondary 
Electrical  Control  Panels  (SECPs)  which  are  co-located  with  the  main 
switchboards  .  The  D86  units  in  the  SECPs  are  also  connected,  by 
serial  data  links,  to  the  communications  sub-system.  There  are  thus  a 
total  of  18  D86  units  connected  to  the  communications  sub-system,  as 
shown  in  Figure  2. 

HEPS  is  not  part  of  HCAS,  but  its  interactions  are  so  strong, 
both  in  control  functions  and  in  provision  of  secondary  surveillance 
data,  that  HCAS  assessment  clearly  required  provision  of  HEPS 
hardware.  This  was  achieved  by  including  a  production  PECP  in  the  SCC 
console  and  procuring  a  D86  unit,  known  as  Alternate  HEPS,  configured 
to  contain  the  functionality  of  the  2  SECP  units.  The  performance  of 
this  unit  did  not  form  a  direct  part  of  the  assessment. 

The  gas  turbine  PCU  contains  relay  logic  for  control  of 
starting,  stopping  and  running  the  gas  turbine,  and  contains  the  fuel 
system  controller,  but  is  not  part  of  HCAS.  The  electric  motor  PCU 
provides  closed  loop  control  of  electric  motor  power  and  performs 
motor  protection  and  start  interlocks,  but  is  not  part  of  HCAS. 
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It  was  accepted  that  HCAS  system  assessment  required  the 
provision  of  both  FCUs  for  one  shaft  whilst  their  functionality  would 
be  simulated  for  the  other  shaft. 

The  total  package  of  equipment  connected  to  the  simulator  is 
illustrated  by  Figure  3.  At  the  interface  the  outputs  from  the 
simulator  represent  transducer  signals  that  would  be  expected  by 
control  and  surveillance  equipment  onboard  a  ship. 

6.2  Equipment  cabling. 

The  see  and  console-installed  d86  units  were  arranged  in  the 
Assessment  Facility  as  per  the  ship  SCC  Installation  (in  terms  of 
relative  positioning).  The  outstation  equipments  were  grouped  to 
represent  their  compartmental  allocation  within  the  machinery  spaces. 

Equipment  cabling  was  prepared,  at  AKE  (WD),  in  advance  of 
equipment  delivery.  The  serial  data  link  cables  were  terminated  by 
standard  connectors.  The  cables  to  carry  hard-wired  signals  between 
the  units  were  terminated  at  one  end  with  lugs  for  use  in  the  screw 
type  terminals  in  the  SCC  consoles,  and  at  the  other  end  with 
multi-pin  plugs  for  connection  to  the  local  D86  units.  The  cable 
reels  were  drawn  from  Naval  stores  with  pattern  numbers  corresponding 
to  ship  details,  but  were  not  made  to  ship’s  lengths.  A  measure  of 
the  cabling  effort  can  be  seen  from  Figure  4. 


Figure  4.  Controls  equipment  cabling. 
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Figure  5.  Simulator  Computer  Configuration 
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6.3  Simulation  detail . 


The  machinery  systems  to  be  simulated  comprised  the  propulsion, 
electrical  power,  and  auxiliary  systems  previously  listed,  together 
with  the  gas  turbine  controller  and  electric  motor  _egulator  for  the 
starboard  shaft. 

ARE  (WD)  was  not  the  sole  body  producing  computer  simulations  of 
Type  23  machinery  systems.  A  Performance  Modelling  Working  Group 
(PMWG),  comprising  MOD,  the  shipbuilder,  equipment  manufacturers 
and  consultants,  was  set  up  to  co-ordinate  aspects  of  simulation 
development.  The  PMWG  maintained  a  data  base  of  machinery 
performance  characteristics,  based  upon  machinery  specifications, 
experimental  and  simulation  data. 

The  level  of  detail  required  within  individual  simulations  in 
the  assessment  facility  was  determined  by  the  importance  of  the 
machinery  systems  to  ship  operation  and  by  the  degree  of  interaction 
between  the  machinery  and  the  control  system.  The  main  propulsion 
elements  are  represented  by  detailed  dynamic  models.  These 
characterise  the  response  of  the  machinery  to  control  system  demands 
over  the  full  operating  profile.  In  other  systems  the  models  are 
much  simpler. 

All  of  the  models  were  developed  specifically  for  the  assessment 
facility  The  approach  was  to  define  the  characteristics  of  the 
systems  and  their  interactions  in  a  set  of  Machinery  Performance 
Definitions  (MPDs)  and  to  use  these  to  write  a  set  of  Simulation 
Performance  Definitions  (SPDs)'  which  could  be  developed  in-house  or 
by  software  sub-contractors. 

These  MPDs  were  sought  after  by  others  involved  with  the 
Type  23,  especially  by  those  preparing  operating  instructions. 

6.4  Simulator  structure. 

Figure  5  shows  the  computer  configuration  used  for  the 
simulator.  Ideally  hardware  decisions  should  be  left  as  late  as 
possible  although  this  must  be  balanced  by  the  need  for  appropriate 
training  before  software  development  can  progress  with  confidence. 
Furthermore  capital  expenditure  will  be  governed  by  the  availability 
of  funds,  which  may  only  exist  for  a  narrow  period  of  time.  In  this 
case  the  hardware  was  purchased  at  the  start  of  the  programme  (late 
1985)  to  meet  capital  expenditure  requirements. 

The  requirement  was  to  procure  a  computer  system  that  would  be 
powerful  enough  to  handle  the  simulation  and  associated  requirements. 
Unfortunately  the  simulator  boundaries  were  not  agreed  at  that  stage 
and  hence  the  required  computational  power  could  only  be  estimated. 
This  was  not  as  unusual  as  it  sounds  because  such  simulation  projects 
are  often  hard  to  quantify  (some  of  the  machinery  systems  may  be 
novel)  and  boundaries  are  often  changed  during  development  ("if  only 
you  could  also  simulate  ...  ").  Thus  the  required  computer  system 
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needed  an  estimated  performance,  together  with  a  safety  margin 
(200%),  with  a  painless  upgrade  path  as  a  further  safeguard. 

A  single  large  computer  within  the  budget  would  not  have  been 
powerful  enough.  Many  small  computers  were  an  attractive  option  but 
would  have  incurred  high  development  costs.  The  MicroVAXes  benefited 
from  the  extensive  support  expected  to  be  available.  The  use  of 
Ethernet  to  interconnect  the  computers  was  attractive  because  of  its 
high  transfer  rates  and  relatively  small  hardware  cost  to  connect 
additional  processors. 

Loading  considerations  required  the  simulation  models  to  be 
split  between  two  computers:  'Slave  1'  and  'Slave  2'.  The  'Master' 
provides  synchronisation,  monitoring  and  data  logging  facilities. 
Table  2  shows  the  simulations  split  between  the  slave  computers. 


TABLE  2. 

Slave  1  Computer. 

Gas  turbine. 

Propulsion  electric  motor. 
Gearbox . 

Transient  brake. 

Clutch. 

Shaft. 

Shaft  brake.  ) 

Propeller  characteristics.  ) 

Starboard  systems  as  for  Port 
+  Regulator  logic. 

Hull  characteristics. 

Fuel  supply. 

Lubricating  oil. 


Slave2  Computer. 
Diesel  generator  (4  off). 
Electrical  distribution. 
Chilled  water  (3  off). 
Refrigeration. 
Ventilation. 

Low  pressure  air. 

High  Pressure  air. 

Special  services  air. 

Low  pressure  salt  water. 
High  pressure  salt  water. 
Aviation  fuel. 
Desalination. 

Fresh  water. 

Sewage 

Bilge  and  sullage. 
Steering. 

Stabilizer. 


Split  of  Simulations  between  the  Slave  Computers. 


) 

) 

)  P 
)  0 
)  R 
)  T 


Each  simulation  model  consists  of  several  subroutines.  There 
are  a  total  of  about  500  such  routines,  manipulating  a  total  of  3500 
variables.  Machinery  co-efficients  and  some  characteristics  are 
stored  in  1500  constants  and  many  look-up  tables  of  various  sizes. 

The  individual  simulation  models  clearly  do  not  act 
independently.  The  values  of  torques  for  example  are  transferred 
between  simulated  machinery  in  the  same  way  as  shafting  connects  the 
real  machinery.  By  siting  the  main  propulsion  simulations  in  the  same 
computer  the  need  for  Information  transfer  between  the  computers  has 
been  kept  down  but  still  totals  60  variables.  For  instance  fuel  tank 
values  are  transferred  from  the  fuel  system  simulation  in  'Slave  1' 
to  the  diesel  generator  simulations  in  'Slave  2'. 
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The  simulatoc,  which  must  operate  in  real  time,  uses  an  overall 
time  step  of  200  milliseconds.  This  is  too  long  for  some  of  the 
dynamics  within  the  gas  turbine  and  electric  motor  simulations,  and 
would  not  satisfy  stability  needs  in  their  local  control  units.  Thus 
software  in  'Slave  1'  only  is  executed  with  a  time  step  of  100 
milliseconds.  Clock  signals  are  generated  and  transmitted  from  the 
'Master'  computer  every  100  milliseconds,  with  every  alternate  signal 
being  ignored  by  'Slave  2'. 

The  facilities  available  to  the  simulator  operator  are: 

*  Simulator  control  (Start, Pause, Resume, Stop) 

*  Dynamic,  or  file-based,  selection  of  simulated  variables  to 
be  monitored. 

*  Dynamic,  or  file-based,  selection  of  simulated  variab''es  to 
be  logged  to  disc,  with  selectable  logging  rate  and 
control  (start, pause, resume, stop)  of  logging. 

*  Dynamic  modification  of  simulated  variables. 

*  Dynamic  modification  of  simulator  outputs,  to  provide  a 
transducer  'freeze'  facility. 

*  Dynamic  selection  of  pre-selected  groups  of  simulator 
outputs  to  be  cyclically  modified. 

Ethernet  carries  the  synchronisation  information,  inter-computer 
simulation  values,  data  recording  requirements  and  the  values  of 
variables  to  be  monitored  or  logged.  The  total  load  on  the  Ethernet 
is  merely  1%  of  its  capacity.  Data  transfers  have  been  sequenced  to 
minimise  the  risk  of  collisions.  Thus  data  communications  were  a  low 
risk  item  in  this  multi-computer  system. 

6.5  Simulator  interface. 


The  simulator  does  not  solely  consist  of  the  computers.  It 
includes  an  interface  in  which  the  floating  point  and  integer  values 
within  the  digital  computers  are  translated  into  the  transducer  and 
actuator  values  expected  by  the  HCAS  system.  The  extensive  digital 
to  analogue  conversion  needed  at  the  interface  was  difficult  to 
achieve  and  required  much  electronic  hardware.  It  was  beyond 
anything  that  could  be  achieved  by  cards  connected  within  the  slave 
computers. 

Manufacturers  of  data  acquisition  equipment  tend  to  service  the 
control  equipment  market  where  there  are  many  analogue  inputs  but 
only  a  few  analogue  outputs.  Few  supply  digital  to  analogue  cards 
which  handle  more  than  four  signals  on  single  euro-card  height  pcb 
assemblies.  This  system  uses  450  digital  to  analogue  converters  and 
caters  for  1250  discrete  signals.  The  cards  require  a  large  space 


3.132 


Figure  7.  Ship  Control  Centre,  at  the  Assessment  Facility. 


3.133 


and  fill  many  racks.  They  need  power  and  absorb  much  calibration 
effort. 

As  shown  in  Figure  5  these  cards  are  contained  in  separate 
cabinets,  one  connected  to  each  slave  computer.  To  minimise  the 
technical  risk  in  this  project  these  interface  sub-systems  were 
purchased  as  essentially  off-the-shelf  systems,  but  the  high 
data-transfer  requirements  combined  with  the  large  number  of  I/O 
channels  limited  the  choice  to  those  that  connected  to  the  computers 
by  parallel  links.  Such  systems  were  not  processor  based,  and 
required  signal  conversion  to  be  performed  in  the  slave  computers. 

Analogue  output  signals  are  not  simply  obtained  by  transferring 
the  floating  point  simulation  value  to  the  appropriate  digital  to 
analogue  channel.  The  value  must  first  be  normalised  and  adjusted  to 
the  range  of  the  converter.  Such  floating  point  arithmetic  is 
processor  intensive  and  presents  a  large  computational  overhead  in 
the  simulation  computers.  In  fact  approximately  30%  processor  power 
in  each  slave  computer  is  consumed  in  signal  conversion.  This 
clearly  impacts  upon  simulation  software  expansion  capability.  In  any 
future  project  (with  possibly  greater  I/O  requirements)  intelligent 
interface  sub-systems  would  be  necessary. 

One  possible  improvement  is  to  connect  the  computers,  by 
high-speed  links  or  network,  to  a  chassis  containing  a  processor  and 
high-speed  links  to  non-intelligent  racks  of  signal  conversion 
hardware.  Such  a  solution  could  safeguard  the  considerable 
investment  in  signal  conversion  hardware  at  TiRE  (WD).  (Despite 
quantity  discounts  the  interface  sub-system  hardware  cost  3  times 
that  of  the  simulator  computer  hardware.) 

The  conversion  hardware  simulates  the  characteristics  of 
transducers  and  sensors,  and  consists  of  a  mixture  of  voltage, 
current,  and  frequency  cards.  Each  card  contains  a  number  of 
channels,  some  channels  are  connected  directly  to  the  SCC,  most  are 
connected  to  local  D86  units.  It  was  decided  that  all  these 
interface  signals  would  be  connected  to  junction  boxes  fitted  between 
the  interface  sub-systems  and  MCAS.  This  allowed  manual  injection  of 
test  signals  and  ease  of  signal  monitoring,  but  added  to  the  cabling 
work  required. 

Figure  6  shows  the  interface  sub-systems,  in  6  foot  high 
cabinets,  separated  by  one  (of  3)  signal  junction  boxes.  The  2  slave 
computers  are  sited  above  the  junction  box. 

6.6  Setting  to  work. 

Cabling  preparation  began  in  mid  1987  and  MCAS  system  equipment 
on  loan  from  the  shipbuilder  was  delivered  between  January  and 
December  1988.  The  extensive  installation  and  setting  to  work 
procedures  completed  in  May  1989  having  followed  the  instructions  of 
drawings  and  documentation  prepared  for  ship  fitting.  Figure  7  shows 
the  MCAS  equipment  in  use  at  the  Assessment  Facility. 
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There  were  many  benefits  from  the  setting  to  work  process. 
Inaccuracies  in  the  drawings  and  problems  with  change  control 
procedures  were  spotted  before  they  hindered  the  ship  building 
process.  As  units  were  set  to  work  their  reliability  could  be 
assessed  and  by  the  end  of  1989  the  equipment  had  been  in  use  for 
over  8000  hours. 

The  multi-pin  connectors  used  between  the  local  086  units  and 
the  see  experienced  pin  displacement  problems  after  repeated 
connections.  The  number  of  repeated  connections  at  AHE  (WD)  was 
higher  than  during  setting-to-work  on  the  ship,  but  indicated  a 
likely  through-life  problem. 

During  development  of  the  electric  motor  regulator  a  prototype 
unit  was  tested  at  the  shore  test  facility  in  Scotland.  Due  to  the 
short  timescale,  modifications  could  not  be  fully  proven  before  the 
facility  was  dismantled.  Early  tests  of  the  first  production 
regulator  against  the  simulation  showed  that  further  modifications 
would  be  needed  before  the  unit  could  be  sent  to  HMS  NORFOLK.  Some 
of  these  tests  involved  unsafe  operating  conditions  which  would  not 
have  been  possible  on  the  real  plant. 

7.  THE  ASSESSMENT  PROCESS 

The  initial  trials,  referred  to  as  Functional  Trials,  compared 
the  performance  of  HCAS  with  that  specified  in  the  STR,  to  confirm 
safe  operation  of  ship  equipment  under  all  normal  operating 
conditions.  These  were  performed  between  August  1988  and  July  1989. 

Functional  Trials  started  with  tests  of  units  within  the  HCAS 
system  against  appropriate  simulations.  They  completed  with  tests  of 
the  whole  system  fully  integrated  with  the  simulator.  Reports 
concluded  that  the  equipment  is  generally  satisfactory  and  identified 
shortcomings.  This  encouraged  changes  to  the  design  where 
modifications  could  be  cost-effectively  implemented. 

The  later  trials,  referred  to  as  Evaluation  Trials,  assessed  the 
peformance  of  MCAS  under  various  operating  conditions  in  order  to 
determine  the  nature  and  extent  of  its  operating  limitations.  These 
trials  included  the  following  tests: 

*  Vulnerability  of  HCAS  to  power  failures. 

*  Evaluation  of  the  'failset'  policy  implemented. 

*  Performance  of  the  Secondary  Surveillance  Facility  under 
various  workloads. 

*  Effects  of  processor  and  communication  loading. 

An  example  of  such  work  was  the  communications  loading  trial. 
This  trial  consisted  of  generating  known  amounts  of  traffic  on  the 
serial  data  links  within  HCAS  to  plot  the  change  in  response  times  of 
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the  secondary  surveillance  facility  and  to  verify  that  high 
comnuni cations  loading  did  not  affect  the  processors'  performance  of 
machinery  control  functions.  The  traffic  was  generated  by  using  the 
simulator  to  change  the  values  of  selected  outputs  on  a  periodic 
basis.  Loading  factors  were  selected  independently  for  each  serial 
data  link,  the  cycling  period  was  also  varied.  The  assessment 
facility  allowed  these  complex  tests  to  be  performed  easily  and 
repeatably. 

A  further  requirement  of  the  assessment  process  was  to  examine 
human  factors  aspects  of  the  MCAS  design.  Several  points  were  raised 
during  the  performance  of  the  Functional  Trials.  A  full  human 
factors  analysis  of  MCAS  was  subsequently  performed,  the  static 
analysis  phase  being  performed  at  the  Assessment  Facility.  This  work 
is  documented  in  Reference  1. 

8.  ADDITIONAL  BENEFITS  FROM  THE  ASSESSMENT  FACILITY 

The  assessment  environment  within  ARE  (WD)  produced  ideas  for 
several  potential  Improvements  to  the  Type  23  MCAS  system. 

Undoubtably  the  most  significant  has  been  tackling  the  problem 
of  what  to  do  with  the  vast  amount  of  information  collected  by  a 
secondary  surveillance  system  monitoring  over  2000  parameters.  The 
Type  23  MCAS  system  automates  the  data  collection  previously  done  by 
hand  and  by  Oecca  Isis  systems.  Like  the  earlier  systems  it  produces 
paper  records  which  must  then  be  monitored,  checked  and  stored.  As 
designed  it  is  relatively  Inflexible  especially  since  it  is  without 
an  interface  facility  for  passing  information  electronically  to  any 
other  on-board  system. 

ARE  (WD)  have  developed  and  demonstrated  a  Personal  Computer 
based  system  capturing  data  from  the  MCAS  system.  It  is  a 
non-interfering,  listening  system  which  can  be  used  to  store  and 
subsequently  to  process  all  data  which  is  sent  to  the  log  and  event 
printers.  The  system  has  very  significant  potential,  as  was 
demonstrated  in  HNS  NORFOLK  during  final  machinery  trials,  and  could 
be  implemented  without  hardware  changes  to  existing  equipment  in  the 
Type  23. 

Users  could  then  search  records  quickly  for  particular  events  or 
trends  and  make  use  of  the  wide  range  of  standard  software  packages. 
Health  monitoring  at  a  system  level  could  be  automated.  Information 
could  be  passed  ashore  electronically  for  further  study  and  not  least 
the  space  and  weight  of  stored  paper  onboard  could  be  radically 
reduced. 

The  Assessment  Facility  was  used  to  help  define  the  Upkeep  Plan 
for  the  Type  23  MCAS.  It  provided  an  ideal  opportunity  for  general 
maintenance  requirements  to  be  thoroughly  assessed  and  proven, 
without  the  limitations  that  would  be  applied  in  alternative 
environments  (on-board  ship,  at  manufacturer's  premises).  The 
facility  was  further  used  to  assess  the  MCAS  diagnostic  facilities. 
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This  was  achieved  by  the  deliberate  introduction  of  signal  faults, 
and  by  the  inclusion  of  faulted  boards,  with  ship's  staff  attempting 
to  diagnose  and  rectify  the  faults. 

The  existence  of  the  Assessment  Facility  also  provided  the 
opportunity  to  evaluate  the  installation  instructions  for  a  damage 
control  data  retrieval  system.  This  had  been  designed  and  developed 
independently  of  the  MCAS  system  although  it  will  be  fitted  within 
the  supervisor's  console.  A  prototype  unit  was  provided  to  ARE  (WD), 
the  resultant  report  recommends  several  fundamental  changes  to  the 
document  and  illustrates  the  value  of  this  small  exercise. 

9.  LESSONS  LEARNT  FROM  THE  ASSESSMENT  PROCESS. 

The  main  lessons  learnt  from  the  assessment  process  were: 

*  Need  to  integrate  assessment  requirements  within  the 
overall  ship  building  programme. 

*  Need  for  early  and  good  quality  documentation  which  should 
include  design  intentions  and  system  operating  principles. 

*  Need  to  design  on  a  system  basis. 

*  Need  for  a  continuous  assessment  programme. 

*  Need  to  allow  time  for  findings  from  assessment  to  be 
actioned. 

*  Need  to  control  software  issue  meticulously. 

*  Difficulty  of  amending  software. 

The  last  2  points  are  related.  Distributed,  digital  MCAS 
systems  at  their  conception  were  claimed  to  be  much  easier  than  their 
pre J.:ressors  to  change.  Experience  has  shown  that  because  very 

cc aprelensive  configuration  control  is  required  software  changes  are 

expc'i' Mve.  Furthermore  the  mechanism  of  incorporating  software 
updates  into  the  control  system  computers  may  generate  further  work. 
For  example  powering-down  the  computers  to  allow  new  Read  Only  Memory 
modules  to  be  inserted  may  incur  the  loss  of  user-provided 

Information,  and  the  consequent  need  for  re-keying. 

The  Type  23  MCAS  system  includes  over  2000  parameters.  Studies 

of  the  Integrated  Platform  Management  System  (IPHS)  concept  suggest 
that  there  could  be  a  several-fold  increase  in  the  number  of 
parameters  within  such  future  systems,  and  more  extensive  use  of 
VDU-based  displays.  System  integration  will  become  more  complex  and 
the  need  for  independent  assessment  even  stronger. 

Steps  to  control  the  number  of  parameters  will  also  be  needed. 
Distributed  principles  should  be  applied  even  to  health  monitoring. 
There  is  a  great  danger  of  too  much  information  being  supplied  to 


central  watchkeepecs  who  only  really  need  a  'healthy'  or  'not 
healthy'  indication. 

10.  SUMMARY 

The  technological  change  from  centralised  analogue  control 
systems  of  previous  warships  to  the  distributed  digital  control 
system  for  the  Type  23  required  a  means  of  assurance  that  the  system 
would  cope  with  normal  and  abnormal  conditions.  Such  assurance  could 
not  have  been  obtained  from  a  machinery  test  facility.  Hence  the  need 
for  a  simulation-based  facility. 

The  production  of  the  Assessment  Facility  has  been  a  major 

project  requiring  the  development  of  a  real-time  simulator  of  the 

Type  23  propulsion,  electjrical  and  auxiliary  systems,  together  with 
extensive  interface  hardware.  Over  30,000  wire  terminations  had  to 
be  made  while  integrating  the  simulator  to  a  production  Type  23  MCAS 
system. 

It  has  been  suggested  (2)  that  the  justification  of  the 

facility  would  lie  in  the  answers  to: 

*  Whether  the  assessment  reduced  the  risks  during  first  of 
class  trials. 

*  Whether  the  assessment  reduced  the  ship  acceptance 
timescale. 

*  Whether  the  facility  would  cope  with  more  advanced 

technology. 

The  assessment  facility  has  helped  notably  to  give  confidence  in 
the  Type  23  HCAS  from  an  early  stage.  It  identified  problems  which 
needed  to  be  rectified  before  they  delayed  the  ship  and  reinforced 
conclusions  from  early  trials  in  the  ship. 

The  simulator  has  worked  well  and  could  cope  with  more  advanced 
technology  both  in  terms  of  the  equipment  under  assessment  and  that 
to  be  used  to  perform  assessment; 

*  Potential  improvements  to  the  interface  arrangements  are 
being  researched  to  cater  for  the  increased  numbers  of 
signals  that  future  plant  management  systems  may  require. 

*  The  facility  could  be  expanded  to  cater  for  more  complex 
simulation  requirements  of  future  systems. 

*  A  computer-based  mimic  display  facility  has  been  added  at 
the  interface  demonstrating  possible  future  approaches. 

The  experience  of  producing  and  operating  the  facility  had 
several  'knowledge'  benefits: 
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*  MOD  has  an  in-depth  knowledge  of  the  HCAS  system. 

*  Ship's  staff  have  enhanced  their  experience  whilst  helping 
with  trials  on  the  equipment. 

*  Maintenance  requirements  have  been  assessed  on  actual 
equipment)  without  interference  to  the  ship  building 
programme. 

The  wide  variety  of  personnel  who  worked  at  the  Assessment 
Facility  made  many  suggestions  for  improvements  to  MCAS.  Some 
suggestions,  such  as  computer  storage  and  analysis  of  secondary 
surveillance  information,  were  then  demonstrated  on  the  facility. 

Tight  timescales  inevitably  mean  that  many  suggestions  will  only 
prove  to  be  cost  effective  for  future  warships.  Maximum  benefit 
could  be  obtained  from  such  input  if  equipment  were  available  for 
assessment  earlier  in  the  production  cycle,  preferable  at  prototype 
stage. 

It  could  be  argued  that  this  could  only  happen  if  the  assessment 
facility  existed  at  the  manufacturer’s  premises,  as  an  extension  of 
their  in-house  test  facility.  This  approach  may  be  be  feasible  if, 
as  in  this  case,  the  system  components  to  be  assessed  were  all 
manufactured  by  the  same  contractor.  The  crucial  question  would  be 
the  Independent  usage  of  that  facility  for  the  role  described  in  this 
paper.  The  'independence'  of  the  assessment  process  is  of  paramount 
importance.  Furthermore  the  use  of  a  test  facility  remote  from  the 
manufacturer's  premises  has  the  benefit  of  reinforcing  the  case  for 
early  supply  of  documentation. 

The  Type  23  equipment  at  ARE  (HO)  is  being  removed,  refurbished 
and  returned  to  a  shipbuilder  for  installation  into  a  future  Type  23, 
now  that  the  objectives  of  assessment  have  been  met.  The  question  of 
a  through-life  simulation-based  reference  facility,  to  allow  testing 
of  control  system  software  and  hardware  updates,  is  currently  being 
addressed.  An  Assessment  Facility  could  clearly  perform  that  role, 
also  enabling  problems  at  sea  to  be  investigated  and  corrected 
ashore . 

Additionally  such  a  facility  could  be  used  in  a  training  cole, 
as  a  supplement,  but  not  replacement  for,  dedicated  training 
facilities.  For  example  the  complete  Type  23  equipment  set  assessed 
at  ARE  (WD)  provided  the  opportunity  for  more  detailed  maintainec 
training  scenarios  than  at  the  official  training  facility. 

Whilst  a  facility  established  to  cover  any  of  these  additional 
coles  would  require  the  outright  purchase  of  a  set  of  controls 
equipment  the  overall  benefits  would  be  considerable,  as  well  as 
providing  the  safeguard  of  an  extra  set  of  equipment  available  as 
immediate  emergency  cover. 

Taking  a  wider  viewpoint  the  question  of  on-board  training 


3.139 


arises.  When  machinery  is  idle,  ship's  staff  have  limited 
opportunity  to  increase  their  understanding  of  the  operation  of  the 
controls  and  machinery  operation.  The  use  of  an  on-board  machinery 
simulator  connected  to  the  controls  equipment  would  be  governed  by 
safety,  cost  and  size.  The  repeat  costs,  and  the  size,  of  a 
simulator  such  as  that  at  ARE  (WO)  are  dictated  by  the  interface 
sub-systems.  However  it  would  loe  possible,  in  this  role,  for  a 
computer-based  simulator  to  communicate  directly  with  the 
computer-based  HCAS  units,  avoiding  the  need  for  much  of  the  signal 
conversion  hardware.  The  safety  aspects  of  switching  between 
simulated  and  physical  machinery  systems  would  have  to  be  addressed, 
but  should  not  present  an  insurmountable  problem. 

11.  CONCLUSIONS 

The  significant  investment  in  independent  assessment  has 
provided  a  very  firm  basis  for  confidence  in  the  Type  23  HCAS  system. 
Although  the  assessment  has  identified  several  aspects  which  could  be 
improved  it  has  confirmed  that  the  Statement  of  Technical 
Requirements  (STR)  is  generally  satisfied.  Through  the  ideas  and 
suggestions  which  have  resulted  from  the  project,  there  is  now  an 
excellent  springboard  from  which  to  develop  much  improved  systems  and 
better  STR  both  for  later  Type  23  frigates  and  for  future  classes  of 
warships. 

Such  independent  assessment  should  be  policy  for  future  ships. 
It  should  be  done  early  and  be  well  resourced.  Consideration  should 
be  given  to  integrating  the  requirements  for  assessment  and  support, 
and  to  providing  a  supplementary  training  facility.  Each  should  be 
addressed  from  a  whole  system  point  of  view. 

12.  DISCLAIMER 

Any  views  expressed  are  those  of  the  authors  and  do  not 
necessarily  represent  those  of  the  Department. 
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DISmEBCrrED  H«XESSC«  OCNISDL  AMD  KXnTCiaMS  SYSTEMS 
-ENSURING  "FTINESS  fCR  H1RR06E”  FOR  IHE  END  USER 
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1.  ABSTRACT 

Distributed  processor  control  and  monitoring  sysbans  are  becoming 
oomnon  fixtures  in  ed.1  types  of  vessel.  They  offer  advant^tges  to  the 
shipbuilder,  ship  owner  and  ship  operator.  The  process  of  stating 
requirements,  manufacturer  selection  and  the  subsequent  development  of  the 
systCT  with  the  manufacturer  are  critical  in  aisuring  'fitness  for  purpose' 
and  it's  inportance  is  often  underestimated  -  perticularly  in  the  marine  and 
offshore  world  -  but  also  in  the  naval  Msrld  when  contracts  cue  treated  on  a 
ooninercial  basis. 

Experience  gained  in  the  technical  auditing  of  offshore  vessels  fitted 
with  such  systems  and  in  the  design  of  these  systems  for  IMG  tankers  amd 
navctl  fleet  r^lenishment  vessels  will  be  discussed.  ESqxerim^  suggests 
that  such  systems  usually  fall  short  of  opectations  in  many  respects  and 
particular  exanples  will  be  given. 

Oonmon  to  eill  vessel  typxes  are  the  reguirements  for  nen-degraded 
performance  under  extreme  cpeiating  conditions  and  a  reasonable  level  of 
fault  and  damage  tolerance.  The  main  factors  to  be  considered  in  the 
selection  and  development  of  systems  to  meet  these  requirements  will  be 
outlined. 

Firally,  the  paper  will  draw  on  the  experience  gained  to  hi^icht 
areas  ripe  for  development  in  the  design  of  these  systems  and  pxropose  sane 
particuleurly  attractive  features  for  the  future. 

2.  INIRXIUCriON 

Distributed  pxrooessor  control  and  monitoring  systems,  those  "new" 
systems  which  d^loy  electronic  conputing  power  euxund  the  vessel  and  which 
utilise  data  hlc^iways  for  connunlcation  purpxxees,  axe  pxercelved  as  offering 
significant  advantages  over  traditional  systems  one  of  which  is  the  ability 
for  the  efficient  handling  of  large  runbezs  of  plant  signals  in  real  time. 
The  phrase  "control  euid  monitoring"  is  based  on  traditional  systems  and 
paxbably  does  not  do  justice  to  the  power  of  the  parooessor  based  systems  or 
the  way  in  which  they  are  enployed.  A  more  appropriate  phrase  is  "control 
and  surveillance". 
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Hhat  is  often  overlooked  is  that  the  traditicnal  systen  with  it's 
nultltude  of  Instiunents  and  ocntxols  cabled  directly  to  the  plant  is  a 
perfect  exaople  of  how  the  new  systene  diould  perfom.  Ihe  traditloral 
systaas  fdso  handle  large  nunbers  of  plant  signals  in  real  time;  a  primitive 
exanple  of  parallel  processing.  Of  oourse  there  is  a  limit  to  the  runber  of 
signals  tdiich  can  be  handled.  After  all,  there  are  physical  limits  in  the 
shipbome  envirannait  for  the  size  and  wei^it  of  the  fgnipmant  needed  to 
han^e  them  and  of  course  limits  on  the  upkeep  and  maintenance  support 
avciilable. 

Present  day  control  and  surveillemoe  systegas  2u?e  nomally  a  ocnbination 
of  "new"  and  triKlitlonal  sfystem  technologic.  See  figure  1. 

"Fitness  for  purpose"  is  a  term  which  in  Itself  is  self  egalanatory  tut 
applied  in  practise,  in  this  case  to  control  and  surveillance  Eystens,  can 
meEoi  different  things  to  different  people.  At  the  plant  level,  in  2ut1 
amongst  the  machinery,  fitness  for  purpcase  is  dictated  by  the  retgulrenents 
of  the  plant  itself  and  it's  operating  philosophy.  Ohere  is  little  room  for 
error  because  plant  manufeKturers  hold  a  wealth  of  eugierienoe  and  even  a 
standard  control  package  is  likely  to  hold  no  more  than  just  a  few, 
inoonvenlent,  operating  idiosyncrasies.  Hore  intangible  is  fitness  for 
purpcae  of  the  shipwide  cxntrol  Euid  surveillance  system;  that  hierarchical 
systen  which  brings  shipwide  control  to  the  fingertips  of  the  operator.  In 
the  context  of  this  paper  fitness  for  purpcae  not  only  cancems  this  system 
but  also  the  operators  and  their  actions  and  reactions.  An  important 
consideration  here  is  the  interface  between  the  systen  and  the  operator;  the 
man  machine  interface  (HMI) . 

It  mst  be  renestered  that  the  developoent  of  the  MD  is  largely  a 
matter  of  historical  oonvmitlon  and  preferred  operational  philosophy. 
Witness  the  differences  in  the  form  and  manning  of  cxritrol  rocns  in  the 
defence,  offshore  and  marine  sectors,  that  is  fitted  is  not  cast  in  concrete 
and  it  is  a  heiilthy  attitude  which  guestions  established  methods  and 
procedures,  that  is  urhealthy  is  if  one  pea±l<ailar  attitude  dcninates  cut  of 
all  proportion  to  it's  value  on  the  project  throu^tcut  the  project  lifetime. 
A  control  toon  designed  by  traditional  aocxuntants  would  be  devoid  of 
instunentation.  At  sea,  an  operator  would  ask  the  cxntrol  rocn  accountant, 
"what  is  the  situation?".  "Is  it  really  essential  to  know  that?",  would  be 
the  recxrded  reply. 

Ihere  are  varicxis  international,  national  and  end  user  "iji-house" 
standards  to  be  followed  and  these  all  help  in  ensuring  a  minimna  acceptable 
quality  is  obtained  but  do  net,  in  themselves,  guarantee  fitness  for 
purpeme.  Hie  aaoeaMnont  of  fitness  for  purpose  must  address  far  more  than 
the  esoteric  aqpects  of  system  design. 

There  are  also  many  piroject  manageroent  tools  which  can  be  employed  but 
these  only  ease  the  process  of  procurement.  They  do  not  ensure  fitness  for 
purpose  although  they  may  in  sene  cases  create  an  environaent  conducive  to 
this  aim.  This  paper  will  address  those  aqpec:ts  in  the  procxrement  process 
which  do  have  a  direct  bearing  on  ensuring  fitness  for  purpose  and  will 
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describe  the  tools  oonsldered  onaontiwl  for  the  teeimlcal  develofuent  of  the 
system. 

there  is  no  hard  and  fast  fomula  for  stMoess  but  experienoe  gzdned  on 
defence,  offshore  and  marine  projects  points  to  there  being  a  preferred  path 
to  follow,  this  paper  will  first  ocnsider  the  managwiifint  of  the  project  from 
the  technical  viewpoint  and  will  the  key  milestones  in  the 
procurement  process. 


there  are  various  reasons  why  cianges  in  direction  take  place  euid 
milestones  move  and  some  of  these  i^l  be  diBCUBswrt  in  terms  of  manaryempnt 
of  the  design  of  the  system. 

Of  edl  inpartance  is  the  eguipnent  itself  and  scse  particular  points 
will  be  mentioned.  3.  MMOGINS  tHE  HCOECT 

Experl^ice  has  oiabled  Shell  Seatex  to  fcnmilate  a  practical  philosophy 
for  the  procurement  of  oonplex  systems  and  ensuring  fitness  for  purpose,  one 
vhlch  has  been  practised  with  distributed  processor  control  and  surveillanoe 
systems  in  both  merchant  marine  and  defence  sectors.  See  figure  2.  Ihe 
fivllcsophy  relies  very  much  on  maintaining  pereomel  continuity  thrcuc^iout 
the  project  and  the  path  Is  marked  cut  fay  the  following  milestones. 

A  statemmit  of  reguirement  for  the  vessel 

Ihe  fomulation  of  the  operational  philosophy 

The  writing  of  a  performance  spec:lflc3atlon 

Ihe  selection  of  a  shipyard 

The  agreement  of  a  contract  specif  Ication 

Ihe  selectlcxi  of  equipnsnt  manufeKrturers 

The  detail  design  stage 

Plan  e^iproval  stage 

Factory  acceptance  testing 

Oommlssloning 

Sea  trials 

The  guarantee  period 
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3.1  h  Statement  of  recmirenent  fnr  w«a.i 


Although  the  reguizemait  is  usueLUy  for  a  new  vessel,  the  philQ6C{iiy 
for  prooirement  can  be  i^jplled  equally  well  to  retro-fit  of  new  eqiilpnent  or 
iqxiating  of  equi|inent  on  existing  vessels. 

Timing  is  crucial.  Ihe  stated  requirement  for  the  vessel  nay  2u:ise  out 
of  years  of  stu^,  in  \toicti  tine  suitable  hardware  solutions  can  be 
researched  if  adequate  budgets  are  2d.located.  More  oft^  tine  for  research 
is  short;  in  this  case  it  nay  help  if  those  involved  with  the  project  are 
curraitly  involved  with  simileur  work  elsewhere  cuid  this  is  one  of  the 
benefits  of  aiploying  someone  \tio  is  used  to  working  as  a  "3rd  party"  and 
vho  has  e;g>erienoe  of  other  aid  user's  reguiremaits.  This  is  a  very 
effective  way  of  introducing  new  ideas  and  questioning  established 
standards,  introkcing  a  process  of  challenge  into  the  fonulatian  of 
requiranents. 


SoBie  particular  end  user  requirements  nay  not  stem  from  purely 
technical  ccnslderations.  Sometimes  there  is  a  necessity  to  demonstrate 
enhanced  safety  features  or  to  nedntain  an  outward  appearanoe  of  being  at 
the  forefront  of  technology.  Scmetimes  budget  limitations  demand  that  an 
"adequate  -  no  more,  no  less"  approach  is  adojpted. 

In  edl  cases  the  operational  philosophy  has  to  be  determined  and 
clearly  stated. 

3.2  Operational  chilosophy 

Possibly  a  more  correct  title  for  this  section  would  be,  "operaticnal 
philosophy,  within  the  allocated  budget  at  any  particular  time". 
Unfortunately,  the  oorttrol  and  monitoring  system  budget  tends  to  be  looked 
on  as  something  which  can  be  triimed  in  favour  of  more  substeoitial  pcu±s  of 
the  vess^,  those  parts  »rtiich  are  more  generally  understood  and  e^reciated. 
This  attitude  should  be  countered.  There  are  opportunities  to  make  long  tern 
cperatlonal  savings,  for  exanple  ty  reduoed  manning  arrangements,  in  return 
for  increased  Initlkl  outlay  and  these  should  be  thorou^Uy  inves^gated. 

Aie  ocnslderatlon  is  the  calibre  of  the  personnel  to  be  employed  to 
operate  and  maintain  the  equipment  when  the  vessel  is  at  sea.  that  is  the 
extent  of  their  e;q)ertise?  To  that  extent  can  their  expjertise  be  rnnheinoed 
ky  training?  What  exp>ert  asslstenoe  can  be  made  availehle  frem  shore  based 
f^K:ilitles  either  by  attendance  or  ccnnunlcation?  Hew  reeKiily  will  shore 
side  expertise  be  made  available? 

If  there  is  limited  expmrt  knowledge  held  by  the  pierscnnel  on  the 
vessel  it  does  not  neoess2u:ily  follow  that  technical  ocnplexi^  of  equipmmit 
should  be  limited.  In  ccnblrmtion  with  system  redundancy,  automated  fault 
analysis,  module  r^lacement  technigues  and  diore  assistance  by 
oonnunlcatlon  and  attendanoe,  operating  and  naintenanoe  pjersonnel  need  only 
be  conversant  with  the  basic  building  blocks  of  the  system  anl  be  familiar 
with  the  basic  terminology. 
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Tlvere  may  be  an  application  here  for  expert  systens;  bridging  the  gap 
between  the  systesn  and  the  operatator. 

If  a  centralised  form  of  ocntrol  is  to  be  adqcted  a  decision  needs  to 
be  made  as  to  the  locations  at  vAiich  these  ocntrol  "roons”  will  be  located 
zuid  the  physical  ccnnunlcatlon  to  be  sifforded  with  other  key  areas  of  the 
vessel.  The  optinum  locations  vary  with  e2tch  class  of  vessel.  In  the  case  of 
the  majority  of  merchant  vessels  the  macdunery  ^eoes  and  the  control  roans 
are  designed  to  operate  unattended.  In  the  event  of  a  machinery  2Llazm  the 
first  point  of  ceill  for  the  duty  engineer  is  usually  the  control  rwau  to 
acknowledge  the  alarm  emd  to  initiate  corrective  eu^tion.  It  is  convenient  to 
have  the  control  room  close  to  the  engineers  aocamodation  on  route  to  the 
machinery  ^aoe;  very  often  the  ocntrol  rocra  is  sited  within  the 
acccmnodaticn  block.  Where  the  machinery  control  roan  and  the  cargo  and 
ballast  control  roans  are  cxxtbined  there  can  be  an  inprovement  in  overall 
ship  cperational  efficiency. 

Also  of  importanoe  is  the  design  of  the  control  infrastructure  in  terms 
of  interooRiunlcaticn  facilities  and  the  cpportunil^  for  delegation  of  work 
by  the  control  roan  operators  to  those  in  other  areas.  The  distibuted 
processor  type  system  donands  a  review  of  tiadltlonal  operating  methods. 
When  it  fails  there  can  be  an  innediate  demand  cn  nanpcMer  rescuroes  for 
it's  r^air  aind  for  the  resunption  and/ca:  maintenanoe  of  cperaticn  at  local 
manual  level.  Such  is  the  nature  of  these  systems  operators  should  practise 
operation  under  simulated  failure  ocnditions  as  part  of  regular  drills 
otherwise  unfamillarlty  will  lead  to  operationed  problems  at  critical  tines. 

An  operating  Ehilosophy  is  an  essential  foundation  stone  in  the  design 
process. 

3.3  Performance  specif icaticn 

The  perfotmanoe  ^ecification  for  the  ocntrol  and  surveillanoe  system 
should  be  just  what  it  says  it  is.  It  should  cxnoentrate  on  the  requiranents 
as  far  as  the  end  user  is  affected  and  should  not  preclude  alternatives  in 
terms  of  equipment  or  system  cxnfiguratlon  unless  this  is  considered 
essential.  Often,  on  a  projec:t  idilch  involves  a  long  period  of  research,  a 
nunher  of  possible  system  manufacturers  eae  included  in  the  early 
feasibility  work.  While  this  is  useful  in  keeping  options  open  and  in 
keying  final  system  costs  at  reeisonable  levels,  care  should  be  exercised  to 
ensure  a  seuiufacturer  who  is  obviocely  not  ce^iable  of  meeting  the 
reqiiirements  for  performanoe  is  relieved  of  further  involvement. 

A  very  useful  inclusion  in  the  performanoe  ^scificaticn  is  the 
reasoning  bdiind  the  requirements.  This  helps  manufacturers  to  assess  their 
own  proposeds  and  acts  as  an  effective  first  line  filter  in  the  approval  and 
selection  process. 
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3.4  Selection  of  the  shljjvard 


In  pcesent  day  clrcumstanoes  the  selection  of  the  rl^it  ^lipyard  is 
even  more  lifjortant  than  ever  before.  Caze  has  to  be  taken  to  ensure  that 
the  neoessaTy  es^iertise  Is  available  either  at  the  yard  Itself  or  by  pro{)er 
subcontract  to  a  r^iutable  organisation. 

Ibe  selection  process  depends  on  nary  factors  and  ney  include  political 
or  other  intangibles.  This,  coupled  with  todays  popular  option  of  delegating 
total  design  responsibility  to  the  shipyard  can  introduce  further  problens. 
A  carefully  considered  caxyesk.  can  be  diluted  out  of  201  recognition  by  a 
shortage  of  eapertlse  at  the  shipyard  coupled  with  l2Kdc  of  technical  sipport 
from  the  end  user. 

3.5  Contract  specification 

There  eue  many  ways  the  contract  specification  can  be  written  to  ensure 
adequate  resources  are  made  available  and  suitable  nanufacturers  sue 
selected.  It  is  often  the  case  that  this  specification  is,  as  far  as  the 
detail  design  is  conoemed,  the  last  chanoe  for  the  end  user  to  inpart  ary 
reed,  influenoe  on  the  fined,  system  form.  The  end  user  will  view  this 
document  as  a  neetns  of  directing  and  guiding  the  shipyard  toward  a  preferred 
solution  euid  the  end  user  will  atteopt  to  use  it  to  steer  a  ocurse  for 
design  developmmt  by  the  shipyard.  Fbr  the  shipyard,  tt^  contract 
^leciflcation  represents  an  agreed  level  of  perfomanoe  for  the  system  and 
the  yard  will  invariably  resi^  ary  attenpt  to  be  tied  down  to  particular 
methods  and  solutions. 

3^5  Selection  of  the  eauicroent  manufacturer 

There  ars  as  nary  manufacturer  selection  processes  as  there  are 
nemufacturers.  Ona  aspect  which  is  always  addressed  but  which  is  very 
difficult  to  control  is  that  of  rescuroes  in  respect  of  people  and 
ei^pnent.  Host  namfacturers  have  extremely  experienced  and  qualified 
people  and  can  demonstrate  excellent  pieces  of  eqidpment  but  these  nay  not 
be  the  ones  to  be  employed  on  your  project,  at  least  not  for  long  after  the 
ccntract  is  awarded.  Even  if  they  are,  if  they  eue  particuleurly  sidled  th^ 
will  almost  certainly  be  shared  betwe^  two  or  laore  similar  projects.  These 
people  are  a  valuable  narufacturers  asset. 

In  nary  cases  manufacturers  lexdc  a  depth  of  esperienoe  traa  the  end 
users  point  of  view.  It  is  only  very  rarely  that  a  narufacturer  will  be  eible 
to  perfom  a  "turn-key"  oontract  in  which  he  eKxurately  identifies  the  end 
users  needs  ajid  meets  his  requirements  in  all  repects.  Wiere  this  is 
successfully  carried  out  the  nanufsxiturer  has  usually  hired  expertise  to 
en2d3le  him  to  do  it.  He  will  only  do  this  of  course  if  he  is  contractually 
obliged  to  do  so,  in  one  fom  or  another,  and  he  has  a  budget  available. 

<kie  of  the  more  inportant  activities  of  the  end  user  is  ensuring  that 
the  contract  between  the  shipyard  and  the  menufacturer  does  not  ccmprcmise 
technical  content. 
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■\.n  npitan  A»n<nn 


It  is  in  the  stage  of  detail  desi^  discussions  that  tiiose  aspects 
viiich  are  peculiar  to  a  manufacturers  oun  equipnent  are  aiddreesed.  IJecteiical 
solutions  rust  be  selected  mhich  allow  the  overall  reguiraoents  to  be  met 
and  for  this  reason  the  process  must  be  led  by  scmeone  with  an  overall 
picture  of  the  project,  niis  can  not  be  2tchieved  efficiently  by  ccenittee. 
Ihere  is  a  sensible  balance  to  be  maintained  between,  on  the  one  hand,  "all 
party  discussions"  in  achieving  end  user's  approval  of  a  particular  solution 
and,  on  the  other  hand,  a  single  person  autiiarised  to  appaxwe  on  the  spot. 
The  former  ensures  all  Interested  parties  have  an  input  and  ttierefore  the 
final  design  will  be  acceptable  to  all  -  in  ttieory.  Ihe  latter  ensures  rapid 
progress.  E>g)erienoe  has  shown  that  apprewal  cn  the  epot,  whenever  this  is 
at  all  possible,  is  the  more  practical  arrangement.  Ihe  authorised  person(s) 
must  also  have  the  necessary  authority  within  the  end  users  camp  to  ensure 
unpopular  solutions  and  even  ocnprcedses  are  accepted  and  that  other  areas 
of  the  project  20%  ocntrolled,  for  example,  to  preserve  interface 
ocnpatabillty  betwemi  systems.  It  is  iitperative  that  the  end  users 
r^)resentative  maintedns  a  level  of  credibility  with  the  shipyard  and 
manufacturer  and  this  can  not  be  achieved  by  hesitation  or  reneging  on 
previous  decisions. 

3.8  Plan-aEProval 

Plan  approval  is  the  process  of  ocnflrmatlon  that  the  end  users 
requirements  are  beii^  met  and  that  the  solutions  agreed  during  design 
discussions  are  being  adhered  to.  Again  it  is  iaportaunt  to  maintain 
credibility  and  therefore  as  ehort  a  period  as  possible  for  approval 
purposes  is  called  for.  In  seme  cases  it  may  be  worthwhile  approving 
drewings  on  the  shipyard  and  manufakoturers  "dramdng  boards",  particularly 
vdiere  early  Influaioe  is  essential,  before  the  design  goes  too  far  down  one 
particular  road. 

3.9  Factory  acceptance  testincr 

The  manufacturer  will  design  the  factory  e»oeptanae  tests  to  prove  the 
system  worte.  It  is  the  responsibility  of  the  end  user  to  oenfirm  at  these 
tests  that  his  requiraments  have  been  net  in  adl  reqpects  and  to  prewe  that 
the  system  ham  acceptable  failure  modes  and  effects.  This  means  that  those 
attending  the  tests  should  be  those  who  tmve  been  involved  throu^iout  the 
project,  those  who  will  be  able  to  lock  beyond  the  black  and  whits  text  of 
the  test  procedures  and  the  staged  demonstrations. 

The  tests  should  Include  an  assessment  of  the  eystem  in  relation  to  the 
shipyards  oonmlsslcnlng  programme. '  If  it  is  proposed  that  the  system  should 
be  ocnnissloned  piece  by  piece  then  the  tests  should  include  pi^  by  piece 
power  up  and  cperatlcn. 

The  tests  should  also  Include  simulated  fadlure  conditions  and  repair 
procedures. 
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Ihe  only  way  a  ocnplex  systaa  can  be  tested  effectively  is  as  a 
ocnplete  systen  and  the  first  tine  the  systan  oones  together  in  this  way 
should  be  at  the  nanifacburers  works.  Tartiary  devices  and  systens  should 
also  be  included  as  far  as  possible,  particulaiy  other  manufacturers 
egoipnent  which  connunlcate  over  data  links. 

Tin  nciiin<«gton1nqr 

Successful  oonnissslcning  relies  on  the  knowledge  of  those  involved 
gained  throu^  documentation  and  training.  Only  a  knowledge  of  ■Nihat  the 
^stan  is  about"  will  enable  aoairate  observations  and  feed  back  to  take 
place.  Operating  maraials  and  drawings  are  eesexitial  tools.  Training  courses 
glvai  by  the  manifacturer  and  the  stdpyazd  design  teams  are  invaluable. 

3.11  Sea  trials 

The  final  proof  lies  in  the  sea  trial  idien  all  systans  lae  running 
together.  This  is  the  final  proof  of  fitness  for  purpose  and  therefore,  once 
the  sysbea  has  beai  provai  to  vntk  as  intaided  it  should  then,  once  again, 
be  subjected  to  simulated  fedlures  to  check  re^xxise.  These  checks  eure 
worthless  without  sane  baseline  against  vdiich  the  results  can  be  measured. 
The  baseline  is  the  original  design  intent  therefore  these  checks  should  be 
attended  by  the  systan  designers.  An  important  aspect  of  the  simulated 
failure  tests  is  the  perfonmnoe  of  the  operators. 

saranteg 

If  the  systan  is  fit  for  purpose  any  claims  under  guarantee  should  be 
limited  to  normal  failures  associated  with  "nmning-in”.  In  the  guarantee 
period  there  is  the  opportunity  to  observe  how  the  settling  down  process 
progresses  and  to  gain  valuable  feaSack  from  the  operators.  The  designers 
must  be  prepared  to  listen  and  if  equipment  or  operational  philosophy 
changes  are  necessary  th^  should  be  iirpleroented  at  the  first  opportunity. 
This  exercise  should  not  be  looked  on  as 

the  result  of  deficiencies  in  the  design  but  an  essential  ovi  stage  of  the 
design  piroaess. 


m  spite  of  all  efforts,  very  often  the  distributed  processor  control 
and  surveillanoe  system  is  not  oompletely  reac^  at  sea  trials  time.  In 
cases  it  turns  out  to  be  never  quite  irfiat  was  intaided.  A  hind  si^  view  is 
a  very  useful  facility  and  those  involved  with  any  project  which  converts 
conceits  into  reality  will  be  able  to  idaitify  with  the  notion  of  "doing  it 
better  the  second  time  around".  Some  of  these  seocnd  tiam  around 
cbservaticns  will  now  be  discussed. 

4.  MANAGING  THE  DESIGN 

There  is  no  dcubt  that  the  end  user  knows  eicactly  what  he  wants  when  it 
comes  to  a  control  and  surveillanoe  system  for  shipwide  applications,  so  too 
does  everyone  else  involved  with  the  specification,  the  purchase,  the  design 
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developnent  and  the  ultimate  setting  to  woidc.  Unfortunately,  everyone 
involved  tends  to  have  their  own  view  of  uhat  the  requirements  really  are 
and  these  views  are,  invariably,  different.  Ihe  end  result  is  often  a 
OQDpixndse* 

At  one  time  the  task  was  relatively  siiiple.  Each  part  of  the  plant 
cxMld  be  looked  upon  as  an  independant  entity  and  those  people  involved  with 
the  control  and  suxveillanoe  aspects,  the  chetin  of  people  fran  end  user  to 
designer,  would  talk  the  same  language  and  there  was  little  opportunity  for 
misinterpretation.  Each  had  sufficient  knowledge  to  eogjress  their 
requiremmits  in  terns  understood  by  all  and  then  to  check  that  these  had 
been  correctly  iaplemaited.  Now  there  seems  to  be  a  necessity  for  the 
transadssion  of  large  amounts  of  data  around  a  vessel  and  no  longer  can  the 
parts  of  the  plant  be  treated  as  independiuit  entities.  Now  the  chain  of 
people  includes  operators,  electrical  engineers,  ocntrol  engineers, 
electronic  engineers  and  software  engineers.  Such  is  the  rate  of  development 
in  these  disciplines,  and  particularly  in  electronics,  that  the  chain  of 
people  is  new  only  teuously  linked  and  there  ajx  far  more  opportunities  for 
misinterpretation.  Each  member  of  Ihe  chain  is  well  versed  in  his  own 
discipline  but  can  only  ever  have  a  cursory  appreciation  of  the  phraseology 
and  methodology  of  the  others.  Ihe  end  user  and  the  software  designer  are 
often  vnrlds  apart;  they  may  use  the  same  words  but  they  talk  a  differeit 
language. 


Ihe  ocntrol  and  surveillanoe  system  usuadly  does  appear  at  the  aid  of 
the  day  and  it  usually  performs  in  a  satisfactory  manner,  the  project  is 
suooessfui  and  is  within  budget  (though  not  necessarily  the  same  budget  the 
project  started  with) .  This  does  not  mean  to  say  that  the  frustration  felt 
by  seme  people,  because  they  are  the  ones  vho  ocnpmiised  the  most  to  make 
it  suooessfUl,  is  made  any  more  tolerable. 

Ihe  reasons  for  conpromise  are  numerous  aund  they  aurise  in  every  prefect 
at  every  stage.  Sane  are  glaringly  obvious  to  outsiders  and  sane  are  subtle 
to  the  extent  that  it  nay  not  be  denmoti  necessary  to  inform  adl  those 
involved  that  a  aaipianise  has  indeed  beoi  made.  Oenpremises  are  necessary 
i4ien  any  one  or  a  oonbinatlon  of  the  following  occur; 

The  end  user  or  his  agoit  has  unrealistic  expectations  of  the 
system. 


The  end  user  or  his  agent  puts  an  unrealistically  low  monetary 
value  on  the  system. 

there  is  insufficient  heliocoter  for  the  interpretation  of 
re^iirements  and  design  oonstralnts  in  caxler  to  reach  a  sensible 
bedanoe. 

the  users  eipectations  tend  to  follow  a  set  pattern  as  he  sets  out  on 
the  learning  curve  for  the  eppllcation  of  distributed  processor  systems. 
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those  "new"  sysbens  cn|>Iaying  data  hi^May^  and  viiich  are  software  driven. 
Initially  a  safe  course  is  steered  by  insisting  that  all  essential  controls 
and  surveillance  signals  be  cabled  inde^endantly  in  the  traditional  uey  and 
only  the  nGn-essential  signals  be  included  in  the  nev  systen.  After  a  chert 
\hlle,  either  through  a  process  of  learning  or  confidentt  building  or  both, 
it  is  realised  that  as  long  as  the  systen  is  engineered  properly,  fault 
toleranoe,  particularly  in  fire  or  damage  situations,  can  be  such  iaprewed 
by  the  use  of  the  new  system  with  all  lt*s  redkxndimcy  features  in  pteferenoe 
to  traditional  cabled  systoos.  there  are  also  reductions  possible  in  the 
amount  of  cable  Insulatlcn  materials  installed.  All  "essential"  signals  are 
thereafter  allocated  to  the  new  systaa. 

the  next  stage  involves  an  analysis  of  the  new  system  with  reflect  to 
installation  and  overall  project  time.  It  is  soon  realised  that  the  new 
system  allows  all  the  initial  design  effort  to  concentrate  on  hardware,  the 
hardware  is  usually  needed  very  early  on  in  the  build  pragranse.  the  process 
of  developing  software  can  be  undertaken  later  when  the  rest  of  the  vessel's 
egu^ment  has  been  better  defined.  In  this  way  the  design  development  peak 
warkload  eogierienoed  at  the  start  of  a  project  can  be  reduced. 

there  are  also  saivings  to  be  made  in  terns  of  reducing  the  nuehers  of 
cables  running  throu^  the  vessel.  With  the  new  system,  cabling  and 
terminations  are  concentrated  into  ^mcific  areas  of  the  vessel  and  there  is 
a  minimum  of  through  ship  cabling  so  reduciig  ^>aoe  and  insteaiation  time 
regiirements.  the  botefits  can  be  nuneraus.  Suddenly  the  new  ^stem  has 
become  very  useful;  every  possible  use  is  made  of  it. 

As  far  as  performanoe  is  oonoemed  the  new  system  has  a  lot  of 
attractions.  Every  control  station  has  the  potential  for  controlling  and 
monitoring  all  the  plant  on  the  vessel.  If  one  control  station  is  lost 
throigi  fire  or  dama^  control  can  revert  to  any  other  convenient  station. 
Data  can  be  transmitted  azeund  the  vessel,  processed,  displ^oed,  duplicated, 
analysed,  time  delayed,  checked,  conditioned,  converted,  archived.,  the 
options  appear  to  be  unlimited.  Oslour  di^tlays  mimidcii^  the  l^out  of 
plant  and  egoipnent  are  used  as  backdrops  for  displayed  data  showing 
measured  values,  alarm  messsiges  and  trend  analysis'  ani  watchkeeper  logs  are 
anreillable  at  the  touch  of  a  button.  Within  seoosds  new  displays  am  be 
brought  to  the  screen  and  dlsplsyed  data  is  ccntinually  updated.  Obe 
specific  characteristics  of  data  bus  systems  whether  they  be  fibre  optic 
links  or  copper  conductors  can  inclrsie  features  to  assure  issunlty  to  the 
effects  of  electrical  interference. 

Hew  these  expectations  are  realised  in  practise  depends  on  how  the 
manufacturer  inteoprets  them  and  relies  very  Mvh  on  a  gualatitive 
assessment  of  each  feature  in  relation  to  the  others  and  in  relation  to  the 
operation  of  the  system  as  a  whole.  Ihls  is  a  key  element  in  the  dsvelcpuent 
of  the  systen  and  reguires  careful  ccnsldeiation  ard  discussion  betwem  all 
parties  concerned. 
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4.2  ManBtarvvalue 


Hie  purchaser  of  ^  ayatai,  His  ahlpyaid  or  the  and  user,  considers 
tha(t  the  new  systca,  on  the  basis  of  awperfanoe  t#ith  traditional  i^etwa,  is 
bound  to  be  a  little  acre  aavansivs.  After  all,  there  i#ill  be  a  lot  of  tine 
and  effort  to  be  client  in  discussing  the  particular  iwjiliiaila  of  such  a 
ooBcOeK  systes.  However,  this  has  to  be  saaeurad  against  the  aavinga  to  be 
had  in  teras  of  installation  oosts  and  the  potanitlal  for  Hiortaning  the 
oonstruction  prograaae.  Owrall,  can  one  probably  aagpect  to  braalc  awan  on  a 
cost  per  signid  basis? 

A  distributed  piTrsewm:  systas  is  a  oo^plsK  oollaction  of  ragniraaents 
and  there  is  alwe^  great  difficulty  in  putting  a  aonstary  value  on  it  xaitil 
it  has  been  dsfinikl  in  detail.  Hiia  leaves  a  lot  of  roos  to  aenoauvre  at  the 
early  stages  of  negotiation.  It  is  quite  an  aasy  taric  for  a  strong 
cceaintdal  teas  to  farce  the  cost  of  such  a  aystaai  down.  It  is  even  easier 
for  a  strong  technical  teas  to  ensure  that  you  only  get  idsat  you  pay  for. 
OoBBercial  and  technical  reprasentatives  should  boHi  be  in  attendance  at  the 
final  pre-purchaae  negotlatlone  between  the  nanufacturer  and  Hie  purchaser. 

Qnoe  the  oast  and  aocpe  of  eupidy  has  been  agreed  there  is  a  tendency 
to  put  the  eefhasis  on  the  sanufactum:  to  devslap  the  design  and  very 
little  soney  is  allocated  to  preside  the  sanifacturer  with  technical 
support,  this  is  sueprising.  An  malyeis  of  the  cost  laenefits  of  Hia  new 
aystcB  Include  a  nhetantial  saving  for  tha  project  in  teres  of  electric 
cable  and  a  reduction  in  installstlon  peak  Norkload.  (Ae  tha  new  aystes 
involves  ^leclfic  areas  of  hi^  density  cable  installation  and  ocmacstiens 
with  little  through  Hilp  cabling,  fewer  teaee  of  electricians  are  needed, 
cue  team  can  be  set  to  week  in  difterant  areas  of  the  veenal  at  different 
tiaes  as  the  steelwork  and  outfit  inTiji-wnoiM  rather  than  having  to  wait 
until  these  are  adbstantially  cxagilete  as  with  traditional  systaesi) . 

All  too  often  the  purdiaaer  places  the  order  and  Han  opts  for  a  Hnrt 
tecB  ga^  by  feUing  to  rseasber  that  dsvBlciaant  work  is  sUll  reguired.  A 
proportion  of  his  purchasing  budget  ahculd  have  been  set  aside  for  technical 
arpport  to  the  nanufacturer.  ftiat  suffers  first  is  sigport  to  the 
nanufacturer  in  terae  of  an  overview;  an  elaaent  of  techni^ 
which  balances  the  raguirasents  of  tha  and  user  against  the  constraints  of 
the  ■anufacturere  dasl^.  An  elanant  called  helicapeer. 

4t3  HBliOBPtg 

Hw  chain  linking  end  user  to  eanufacturar  relies  cn  clear 
ccBeunication  of  regalreesnts  and  oenstraints  (they  flow  in  opposite 
diiectlone)  and  as  long  as  this  is  done  effectively  at  all  etagas  of  the 
project  than  Hiete  is  no  reaaon  why  Hnre  Huuld  be  aiv  auqprlaoe  cr 
diaappointaants  later  on.  Ihe  length  of  Hiia  chain  and  the  diaci{d.lneB  of 
the  people  who  nake  the  links  varies  aooarding  to  the  project  ennmjineiir 
technlqiiae  favoured  for  any  perttcular  project,  nreieiilratli  n  tends  to  break 
deem  whan  people  decide  to  stay  where  titey  arm  aost  ooefortabla,  in  their 
cam  field  of  activity,  stating  their  own  case  and  leaving  others  to  oase  up 
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with  aciprofariate  solutionB  no  Bcitber  bcw  difficult  this  my  be.  a  dwdn 
this  can  be  tine  wasting  and  ineffective.  Contractual  and  financial 
llnitatlons  pcoaote  1aolat1»laa  and  Mebers  of  tiie  chain  atbogpt  to  mate 
others  take  the  lead  In  pcewldlng  a  technical  oo-^scdinaticn  service,  a  role 
in  ahiidi  trenma  talaes  it  on  theeaelvss  to  talk  to  all  isst  iriTT  and  sensibly 
balance  reqaineents  against  constraints  all  down  the  line.  It  is  eoqpenslve 
to  take  on  this  role.  A  strong  end  user  or  purchaser  can  distance  hieself 
frcn  the  desigwr  or  eanufacturar  and  say  employ  ocntractual  tactics  rather 
than  ccanit  a  proper  budget  for  the  provision  of  technical  guidance  and 
co-ordination  or  "hellooptec". 

Althcu^  the  hellac{)ter  eleeent  can  be  provided  by  others  cutwith  the 
chain  it  has  sost  effect  if  this  eltiwnt  is  provided  by  soseone  directly 
involved,  preferably  acenane  with  the  authority  to  sodify  reqalrseentB  as 
the  design  develops  and  constraints  are  realised,  dhis  infers  that 
helicopter  is  best  provided  by  ncnaone  in  the  chain  close  to  the  end  user. 

S.  BUHDDIS  ns  FOJMDKnOMS 

In  developing  the  oonoepts  the  end  user  or  his  agent  lust  ask  the 
question,  "what  is  the  purpose  of  the  systeei, . .  .what  is  it  supposed  to  do?" 

era  of  the  nore  otvlcus  acnslderatlora  is  the  way  in  which  the  systeai 
will  be  used  on  board  the  vessel.  Ihis  depends  on  the  calibre  of  people 
esplayed,  their  training  and  their  culture.  Ihe  system  is  an  aid  to  the 
operators  in  perforadng  their  duties  and  lAxaild  enhance  the  safety  and 
efficiency  of  their  actions. 

There  are  nuneroue  aystae  aanfl^irBtionB  paesible  but  it  is  unlikely 
that  any  particular  arranganent  could  or  diould  be  chosen  at  the  concept 
stage.  Wiat  is  aars  iipactant  is  that  the  sain  operational  features  and 
characberistloB  are  addreeeed.  The  end  user  should  try  to  establi^  a 
sensible  balance  between  what  would  be  nice  to  have  froa  the  operators  point 
of  view  and  what  is,  in  reBlity,  a  practical  proposition  all  things 
oonsldetsd. 

De^iite  the  wide  eagwrienoe  of  the  "new"  distributed  prooessor  systaee 
there  la  still  an  cverriding  influence  froa  ea^erienoe  with  traditional 
aystaas  where  witchee,  Indlcatora,  dials  and  a  plethora  of  cehles  and  wires 
is  the  noKB.  The  traditional  systess  are  well  tried  and  tnntrri  and  tiieir 
shartacninge  are  well  docmented.  The  orrmp^imi  design  of  the  new  ^staas 
is  still  nsanxred  against  the  advantages  and  disadvantages  of  the 
traditional  systeas. 

Bqperlsnoe  has  etxMn  that  it  is  not  just  a  case  of  changing  ftca  old 
technology  ocntiol  and  survalllanoe  syatam  to  new  technology  systeas.  There 
are  iapUcatlora  for  ttw  design  of  plant  and  to  111.1.1  an, lute  new 

ideas  Mch  as  raduoad  aeiming  and  autcaeitlon  on  a  ahlpwlde  aoale.  The 
control  and  airvelllanaa  systaa  designer  hea  to  iiwolve  hiseelf  sore  than 
aver  before  in  the  deelyi  of  the  vsesels  engineering  ayateae  and  in  the 
re  annnlintlm  of  eatabllriied  cperaticnal  aethoda.  There  la  alao  the  prcblae 
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of  tqpkeep.  Kgdntenanoe  and  the  aanseqdentlal  effects  of  cystait  failuce  eune 
essential  ocnslderatlons  in  the  oonneptiial  design  of  a  systen  which  extends 
thrcughcut  the  vessel  and  which  is  relied  qpcn  to  fulfil  so  sery 
reguirenents. 

Features  which  si:{ipart  reduced  Banning  and  reduced  opexatar  workloeKi 
can  be  Included  at  the  ocnceptual  design  stage  with  minimal  effect  on 
overall  costs  and  project  ooecdLetlon  tine.  Ihese  features  are  generally  very 
siii(>le  atnd  can  include  facilities  which  allow,  throu^  nomal  cperational 
practise,  the  routine  testing  of  eguipment;  not  just  the  Bajor  units  and 
asseehlies  but  the  underlying  control  and  protective  features  also.  In  all 
cases  the  egiproach  to  be  adopted  is  to  design  the  systen  and  the  operational 
prooedures  so  that,  as  a  Batter  of  routine,  tee  day  to  day  operation  of  the 
vessel  results  in  a  thorough  chectout  of  all  features.  If  this  is  doie 
properly  all  periodic  perfannanoe  checte  can  be  achieved  as  a  bacdtground 
activity. 

As  an  escaaple,  consider  a  two  puip  schaBe  for  aooling  water  sipplies. 
Nonnally  one  ptaip  is  running  as  tee  duty  puip  and  one  putp  is  on  standby 
ready  to  start  if  the  water  pressure  falls  (if  tee  duty  ptBip  stops).  By 
allowing  the  operator  to  change  the  oonfiguraticn  sisply  by  stepping  the 
duty  punp  he  can  observe  teat  the  standby  punp  automatically  starts.  Hot 
only  has  an  operational  requirement  been  fulfilled  (say,  to  balance  running 
heurs  on  the  machines),  hut  also  a  periodic  function  check  of  tee  control 
devices  Initiating  the  start  of  the  standby  punp.  This  prewes  the 
arrangamait  without  reocurse  to  dedicated  planned  Bedntenance  checks. 
Another  opportunity  with  this  exanple  is  to  provide  a  check  on  the 
availability  of  the  standby  punp  both  at  the  time  it  is  initially  selected 
and  tee  teole  of  tee  time  it  is  on  stanefcy  ty  ensuring  teat  the  design  of 
the  control  egiipment  for  the  Botor  allows  sinple  Bmitoring  of  power 
supplies  and  interlocks.  See  figure  3.  In  this  way  it's  correct  operation 
vhen  called  xpon  is  assured  as  faur  as  possible.  Ihe  operator  is  alerted  to  a 
fault  at  the  tiam  it  oocurs  and  not  at  a  critical  tine  when  tee  standby  pimp 
is  called  upon  and  falls  to  perfam. 

Identifying  faults  as  they  occur  (avoiding  hidden  failures)  can  avoid 
major  failure  incidents. 

6.  IHE  HAN  HKHIME  IMESfACE 

Distributed  processing  can  be  considered  as  a  Bieans  of  processing 
oarller  In  the  data  collection  cycle  and  so  reducing  tee  prooessing  required 
attee  system  "centre".  Ihe  effect  is  to  iaprove  tee  cwerall  performance  and 
ocmes  from  increasing  tea  ramher  of  siBultansous  prooessing  eperations  being 
carried  out. 

There  is  alwqs  a  tenpteticn  to  oake  sure  teat  operators  are  in  a 
position  to  monitor  all  these  processing  operations  by  bringing  back  to  a 
oentrel  control  room  as  much  data  as  possible.  This  can  overload  tee 
operator  rather  than  aselst  him.  The  right  balance  can  be  achieved  by 
ooneidering  the  eperator  as  part  of  the  ayatem  hierarchy  and  aiming  to 
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reduce  his  ptooesslng  task  by  delegation  and  distribution  as  for  the  systan 
itself.  Of  course  there  are  eeaentlal  data  that  he  oust  either  be  aware  of 
or  have  access  to  and  these  should  be  presented  to  him  in  the  clearest  and 
most  infomative  way. 

fi.l  Vlawl  dianlav  unit  fVIXn  wmia  r<<a.;Traiii 

Ihe  VDU  is  a  window  onto  the  plant  with  acne  interpretation  of  the 
plant  paraoieterB  either  by  data  processing  or  in  the  design  of  Idae  VDU  page 
presentation.  One  screen  can  preside  a  reasonable  sized  window. . .  but  still 
only  a  window.  Moving  around  using  this  window  tends  to  be  slow  and 
restricting  and  therefore  novanents  of  this  t^n  need  to  be  minimised.  As 
control  actions  tend  to  be  restrlcdied  when  using  VDU's  automatic  sec|oencing 
should  be  employed  as  nuch  as  possible. 

the  nan  machine  interface  can  siapllfy  or  escasperate  the  opecators 
task.  It  must  be  designed  correctly  in  relatim  to  the  plant  and  the  actions 
ej^)ecbed  from  the  operator.  It  is  very  difficult  for  VDU's  to  outperform  the 
traditional  console  mounted  mimic  diagram;  a  siaple  arrangement  which  can 
provide  a  cxmpirdienslve  overview  of  the  plant  by  careful  attention  to  it's 
design. 


the  fundamental  reguirement  is  to  present  the  operator  with  the 
infomation  and  the  cxxitrol  facilltiee  he  needs  to  perform  his  duties  under 
all  fonsseeable  circumstances,  cne  can  imagine  his  task  in  terms  of  three 
specific  steps  ■■  check  a  plant  feature,  assess  the  situation  and  take 
appropriate  action,  the  operator  performs  these  steps  oontinuously  under 
normal  and  abnormal  oonditions  the  only  differenoe  being  the  degree  of 
urgency  in  each  case.  Ohe  nan  machine  interface  must  maintain  the  efficient 
transfer  of  information  and  control  aemmands  uider  all  operating  cenditiens. 
If  this  transfer  faulters  the  operator  will  not  be  able  to  oonctzuct  his 
mmital  picture  of  the  situation  and  the  man  machine  interface  will  collapse 
into  a  meaningless  mass  of  indications  inviting  operator  error. 

Ihese  ideas  are  best  presented  in  relation  to  a  real  situation. 
Oonsider  for  SKanple  an  oil  cargo  i^stem.  There  my  be  three  different 
classes  of  cargo,  fuel  oil,  aveat  and  lubricating  oil  each  with  it's  own 
set  of  tanks,  valves,  pipelines  and  pimps.  The  electrical  sipplies  to  the 
system  and  particularly  the  cargo  pimp  motare  is  anottier  izilgue  "set"  of 
plant.  Yet  another  is  the  "set"  of  taidc  level  indications  which,  among  other 
uses,  are  enployed  for  strength  and  stability  checks. 

Each  of  these  sets  of  plant  can  be  thou^  of  as  being  represented  by  a 
set  of  plant  Infcrmaticn  which  should  be  readily  available  to  the  operator 
in  an  unclutterd  form.  The  traklltional  mimic  diagram  can  ooshine  large 
ramhers  of  such  sets  of  information  and  clarity  in  presentation  is  achieved 
threue^  cnlcur  coding  of  pipelinas,  ocBMon  designs  of  indloators  and 
controls  for  similar  pieces  of  plant  equipment  such  as  valves  and  motare  and 
tank  level  gauges,  and  the  sensible  groping  of  plant  with  rramm 
functionality,  for  example,  manifold  valves  and  pimp  rocm  equipment.  The 
design  of  the  mimic  in  terms  of  what  operator  sees,  the  shapes  and 
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cslcurs  emd  the  groups  and  sUbgrot^,  is  a  fons  of  data  prooessing  which 
existed  Icng  before  the  advent  of  the  ocnputer. 

For  redooed  manning  cperatlcn,  where  a  ocntrol  rocn  aay  go  unattended 
for  long  periods,  the  operator  needs  a  syeten  of  dicplay  trith  which  he  can 
gain  an  ianediate  overview  of  the  plant  on  his  return.  Oils  can  be  achieved 
^th  the  edoption  of  the  "all  dark"  principle  whereby  changes  in  plant  set 
up  can  be  highlighted  inaadlately  ty  a  single  indicating  lanp.  Ihe  operator 
extinguishes  the  laap  thereby  adoxwledging  the  change  in  plant  staitus.  Once 
again,  this  is  applying  a  form  of  data  prooessing  to  produce  a  more 
efficient  and  hence  more  effective  man  machine  interface. 

How  are  these  features  reproduced  on  ttie  VCU  screen? 

In  the  case  of  the  VDU  screen  the  sets  of  plant  information  dxaild 
still  be  displayed  in  a  clear  and  concise  way.  Although  the  option  of 
oolours  and  shapes  is  still  available  there  is  a  limit  to  hew  much  can  be 
achieved  by  design  of  the  dii^>lay  pages  tbenselves  and  most  of  the 
prooessing  has  to  be  Isplenenbed  in  software.  In  ocBparisen  to  the  ocnshle 
mimic  there  the  various  sets  of  plant  infermatien  are  laid  cut  on  a  fxmiirn 
plane  the  VDU  baaed  mimic  can  be  theu^  of  as  a  set  of  pages,  each  page 
representing  a  different  set  of  plant  Information.  The  VDU  sccreen  is  a 
multidimensional  device  and  involves  an  operating  overhead  in  terms  of  the 
prooessing  power  recgulred  to  permit  the  operator  to  move  between  these  pages 
of  information  in  a  logical  way.  In  acne  VDU  baaed  systaas  this  overhead  is 
or  has  been  ooiltted  and  operators  can  find  themselves  confronted  by  a  system 
of  many  (in  emcess  of  75)  pages  with  no  sensible  means  of  naivigating  throu^ 
the  mass  of  data  involved. 

The  most  oomnen  "navigation"  systems  for  VDU  page  "libraries”  employ 
overview  pages  directly  leading  the  operator  to  more  detailed  psges  on 
^jsciflc  areas  of  plant.  Every  page  di^dayed  includes  pointers  to  related 
pages  which  may  hold  relevant  infbimaticn.  Ihe  best  eystems  are  oonstructed 
in  the  form  of  fUlly  indexed  and  cross  referenced  nanMig  and  allow  the 
operator  movement  from  page  to  related  page  with  single  keyectroks  achlons. 

It  is  fedrly  obvious  that  the  VDU  is  nc3t  a  device  with  a  traditional 
egulvalent  eoooept  maybe  the  operators  manual.  It  reejuires  a  different 
philosophy  for  it's  use.  To  be  esployed  effectively  by  the  eystaa  designer 
it  demands  a  clear  understanding  of  just  what  is  regui^  by  the  operator  in 
terms  of  automation  and  remote  control. 

6.2  flutomation  versus  remote  control 

It  is  Important  to  recognise  the  relative  advantages  and  disadvantages 
of  automation  and  remote  control.  Itemote  ccntrol  allows  an  operator  to 
perform  his  tasks  from  a  more  convenient  position,  usually  a  central  oontrol 
room.  Although  signal  prooessing  may  be  esplayed  in  the  txanenisslon  of 
signals  and  data  in  a  remote  oontrol  scheme,  for  exasple,  by  the  use  of 
signal  multiplexing  techniques,  this  is  not  considered  to  be  distributed 
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processing  in  the  oontext  of  this  paper.  Operator  action  is  an  integral  and 
essential  part  of  rencte  ocntiol. 

Autonation  is  a  feature  vdiich  effectively  reduces  the  central 
processing  regulranents  and  is  therefore  well  suited  for  inplenentation  in 
distriluted  processor  systenB.  There  is  no  requirement  for  op^tor  action, 
under  narnial  circunstances,  in  the  true  application  of  automation. 

Some  applications  axe  best  perfarmed  by  remote  control  and  these  tend 
to  be  those  whiofa  rely  on  "operator  re-infaroement"  of  control  decisions; 
those  applications  whioh  require  acnfimeition  by  the  operator  that  the 
control  solution  is  acceptable.  A  good  exanple  is  the  control  of  oil  Ccugo 
transfer  operations  vhere  ocnnunication  is  required,  maybe  with  another 
vessel,  to  co-ordinate  the  operation,  a  nunber  of  pipeline  valves  need  to  be 
opened  and  punps  have  to  be  controlled. 

Automatic  control,  by  definition,  needs  very  little  operator 
intervention  and  should  proceed  as  a  background  activity  leanring  the 
operator  to  tend  to  more  iiiportant  things.  For  these  applications  all  the 
operator  needs  is  information  alerting  him  if  the  automation  is  not  Morking 
ais  intended.  Very  often  the  mistake  is  made  that  the  operator  is  shown  the 
automated  process  without  being  shown  the  elements  of  automation.  For 
exanple,  in  a  scheme  to  automatically  control  the  production  of  steam  fran  a 
combined  oil  and  gas  burning  boiler  it  is  usual  to  find  the  operator  is 
quite  rightly  presented  with  the  key  process  parameters  such  as  oil/gas  mass 
flow,  farced  drauc^  air  mass  flow,  boiler  drum  level,  steam  pressure  and  so 
on  and  is  given  aooess  to  the  oontrollers  involved  by  which  he  can  alter 
control  set  points,  gains  and  other  features.  Only  rarely  is  he  also  given 
the  information  vhich  relates  the  oontrollers  to  each  other  so  that  he  is 
aware  of  the  interactions  at  each  stage  of  the  process.  By  observing  the 
action  and  reaction  of  the  automation  equipment  he  would  gain  a  better 
understanding  of  the  isplicatlons  of  the  a^ustments  and  fine  tuning  he 
invariably  attenpts  in  the  ocurse  of  his  duties. 

It  is  remarkable  that  on  a  systaa  basis  there  is  always  a  tendency  to 
overee^timate  the  cepability  of  a  distributed  processor  systan  euid  very  oftai 
performanoe  suffers  because  the  system  is  asked  to  cope  with  all  sorts  of 
ocspllcated  tasks  involving  data  from  all  around  the  vessel.  Mien  it  ocmes 
to  the  man  machine  interface  the  opposite  is  generally  true;  t^ing  up 
valuable  processing  pcwer  to  carry  cut  sinple  operations  like  illuminating  a 
group  of  light  emitting  diodes  or  simulating  "on  screen"  iaages  of  dialled 
instruments  when  a  more  cost  effective,  dedicated  digital  circuit  or 
instrument  would  do  the  job  more  efficiently. 

Another  exanple  is  the  use  of  eppllcation  software  to  replace  the 
perfectly  adequate  built-in  logic  iiv^ved  with  different  designs  of 
electrcaagnetic  relays  for  timing,  interlock  and  latching  eplicaticns. 

Of  course,  when  it  oomes  to  safety  related  functions  it  is  essential  and 
generally  more  cost  effective  to  esplcy  dedicated  systems. 
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6.3  Hie  ricflit  mi  for  the  ootitml  sctwme 


Remote  mamiai  ootitXDl  o£  car^o  and  balleusfc  c{)era£lcns,  for  eseanple, 
require  the  operator  to  have  an  cK/ervlew  of  the  ceunqo  and  hallast  systens. 
He  should  not  oonoaitxate  on  one  part  in  isolation  because,  uhile  filling 
one  tank  another  nay  be  filling  via  an  inadvertently  opoied  valve  soneidiete 
else  in  the  systan.  In  this  it  could  be  considered  foolhardy  to  operate 
via  VCU  screens  and  ke^xiarcls  if  the  systao  being  controlled  is  at  2d.l 
extaisive.  This  anangeaent  nay  Indeed  turn  into  an  esqpensive  arcade  type 
game  with  the  operator  Variously  rattling  the  ke^aoard  in  an  attespt  to 
initiate  the  ri^  cxmaands  at  the  ri^  time.  It  Mould  be  more  2qpprcpriate 
to  provide  a  console  arrangenent  vdth  individual  control  and  monitoring 
devices  Incorparated  into  miMc  diagraas. 

An  i^lication  for  integrated  autoeatic  control  may  be  found  in  a 
machinery  control  scheme.  There  may  be  dedicated  software  driven  control 
units  loc2d  to  the  machinery  idilch  cconunicate  to  a  central  management 
system  in  the  control  room  for  remote  control  and  surveillance  purposes.  The 
omtrol  room  operator  will  usuadly  have  the  facility  to  initiate  set  control 
sequences  and  modify  control  settings  to  g2dn  optimum  plant  conditions.  In 
this  case  there  etre  few  problems  involved  when  ii^lementing  this  schone  with 
vcu  screens  and  keyboards  as  long  as  the  independance  of  the  locad  control 
unit  is  assured  and  safety  functions  are  provided  in  addition.  In  this  way 
failures  in  the  central  managanmit  system  would  be  contained  and  the 
operator  could  concaitrate  on  repairing  the  fault  and  not  have  to  worry 
about  the  safe  continued  operation  of  the  machinery.  The  operator  di^lays 
would  be  more  for  the  analysis  of  data  than  the  operation  of  the  plant.  A 
development  here  could  be  the  inclusion  of  decision  making  features  in  the 
management  ^stem  to  assist  the  operator  in  identifying  optimising 
strategies.  Some  proprletxy  control  equipment  include  this  feature  edready. 

There  are  of  course  educations  idiich  do  not  fedl  conveniently  into 
one  or  the  other  categories,  some  vdiioh  would  benefit  by  a  mix  of  VDU  screen 
and  console  mimic  feKzllitles.  Eetch  must  be  considered  on  it's  own  merit. 

6.4  The  function  of  the  oontrol  rocm(s> 

In  modem  merchant  vessels  the  oontrol  room  is  only  a  data  handling 
area  linked  to  the  equipment  actually  controlling  the  plant  by  data  hig^iways 
vhioh  may  also  serve  to  carry  sign^  around  the  vessel.  It  is  considered 
good  practise  to  ensure  that  no  automatic  control  idgorithm  depends  on  these 
"oonraon  usage"  data  hlc^iways  for  continued  operation.  The  data  hi^may  (znd 
the  data  highway  associated  devices)  should  be  considered  an  integral  part 
of  the  control  room  MU  whioh  should  itself  be  a  non-essential  part  of  the 
plant.  All  plant  should  be  capable  of  local  operation  with  plant  mounted 
instrumentation  and  controls  in  aanjiax±icn  with  plant  mounted  indepmidant 
siifety  devices  active  under  all  modes  of  oontrol.  Those  oontrol  features 
vdiioh  are  essential  in  presiding  the  control  room  operator  with  the  back-^ 
means  of  nmiirtalning,  for  instmoe,  manoeuvring  capability  in  the  event  of 
processor  failure,  should  also  be  independant  of  the  data  highways. 
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While  this  approach  reduces  the  critical  nature  of  the  ^lipwide  ocntrol 
and  surveillance  system  it  does  not  pemit  a  relaxation  in  the  requirenent 
for  the  system  to  perform  adequately  under  2lL1  foreseeable  ciramstanoes. 
Experience  gained  in  the  technical  auditing  of  offshore  vessels  fitted  with 
these  systems  and  in  the  design  of  these  eyetems  for  liquid  natural  gas 
carriers  and  naval  fleet  auxiliary  vessels  suggests  that  perfomanoe  can 
fall  ahcot  of  eag)ecbatiaiiB. 

The  notion,  for  instance,  that  the  responsibility  for  control 
oo-ordinatlcn  can  be  transferred  from  one  control  rocm  to  another  as  Icng  as 
there  is  a  woidtstatian  (VDU  or  software  driven  ocnsole  facility)  available 
is  practical,  but  only  under  ncrmal  operating  ocnditions.  The  transfer  is 
usually  isplemaited  by  dt^licating  or  transferring  the  MU;  the  system  data 
base  and  the  operating  system  processing  facilll^  usually  remains  in  the 
same  location.  A  true  transfer  facilii^,  effective  under  damage  oonditicns, 
VKUld  need  to  be  inplemented  in  the  form  of  diplicated  systems  including 
independant  plant  signal  Interfaoe  devloes,  data  highways  emd  control  rocm 
mi. 


Although  many  systems  boast  a  range  of  features  and  facilities  such  as 
multiple  access  for  control  and  surveillance  purposes  in  practise  the  nunber 
of  simultaneous  operations  is  limited. 

Mai^  of  the  shortcomings  in  these  systems  arise  out  of  timing  problems. 
There  are  inherent  delays  involved  with  data  sampling,  trananission, 
processing  and  di^lay  and  vhile  these  delays  may  be  tolerable  for  the  range 
of  normal  operations  they  may  become  inhibiting  «hen  the  system  is  called  on 
to  perform  under  abnormal  ocnditions.  Timing  of  signals  is  crucial  and 
although  different  qgplicaticns  have  different  reguirements  generally 
speaking  time  delays  sh^d  be  kept  to  a  miidsus. 

When  systems  are  gradually  loaded  in  terms  of  data  changes  and 
processing  demands  they  gmierally  slow  down  and  response  times  can  beocme 
excessive.  VDU  displays  have  bemi  seen  to  take  in  excess  of  20  seconds  to 
respcxid  to  operator  requests  under  these  oonditicns  and  sene  systems  have 
even  given  the  inpresslcn  of  coming  to  a  halt;  the  processor  equivalent  to 
stedling  the  o^lne.  Anedogue  tank  level  indications  on  one  particular 
vessel  were  taking  in  excess  of  t*re  minutes  for  sample  and  di^lay  cycles. 

vessel  was  fitted  with  a  system  which  performed  adequately  under  normal 
conditions  but  in  the  period  iamediately  following  a  plant  shutdown  (a  total 
failure  of  the  electrical  system)  the  system  cculd  not  cope  with  the  im»«  of 
alarms  and  ocntrol  signals  suddenly  arising. 

The  sane  is  true  for  operating  personnel.  VBille  they  may  be  perfectly 
capable  of  performing  their  tas)cs  under  normal  oonditicns  therm  are 
eoperi^xms  of  confusion  and  chexs  vhen  thingh  steurt  to  go  wrong.  Many 
serious  incidents  have  beai  caused  by  eperator  error  tiecause  of  poor  )MI 
design.  In  the  majority  of  cases  of  incidents  with  which  we  have  had 
eqmrienoe  etxars  heve  eudsen  due  to  the  qperatOL  Iseing  unable  or  unwilling 
to  construct  an  accurate  mental  picture  of  the  situation,  crisis  training 
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for  operators  is  inixirtant  and  Shell  Seatex  test  this  aspect  of  perfomenoe 
in  sisulated  failure  cxrditlons  as  part  of  tectolcal  auditing  ptooedures. 

7.  GCTTINS  IHE  IDEAS  ACR36S 

CtKse  the  oonoept  has  been  defined  it  Is  then  necessary  to  eoqplain  the 
conoept  to  those  responsible  for  getting  the  system  built.  How  well  this  is 
achieved  will  dictate  the  ease  or  otherwise  %d.th  which  the  design 
progresses. 


It  is  often  said  that  the  biggest  problem  facing  the  shipbuilder  is  in 
engineering  the  interf2K3es  between  systems  frcm  different  narufacturers. 
this  is  often  an  understatement. 

Ihere  are  interfaces  to  be  addressed  in  all  areas  of  the  vessel  design, 
not  only  in  the  sense  of  systans  from  different  manufactures  but  also  in  the 
process  of  design  of  the  control  and  surveillanoe  system  itself.  The 
isportanoe  of  "helicopter"  in  the  chain  of  people  involved  with  the 
development  of  the  system  has  alreac^  beai  atentloned.  It  is  the  interface 
mismatch  betwemi  each  liidc  in  the  hunan  chain  that  helicopter  cxnpensates 
for.  At  some  stage  each  menber  of  the  chain  must  be  presented  with  a  c^ear 
picture  of  «hat  is  going  on,  vhat  is  actually  regui:^  to  be  designed  and 
built  and  vhen  it  is  going  to  h2^p)en.  The  end  user,  the  operator,  must  be 
ccnfident  that  he  is  going  to  get  exactly  what  the  manufacturer  has  agreed 
he  will  get.  There  is  no  room  for  anbiguities  and  misinterpretation.  How  is 
this  assured? 

There  are  four  essential  tools  reguired  for  the  development  of  a 
distributed  pnxxssor  cmtrol  and  surveillanoe  syston.  These  can  take  many 
forms  but  their  purpose  remains  the  same.  They  are; 

system  ^)ecificatian 

A  document  which  defines  the  cperatioral  philosopiiy,  the  extent  of  the 
system,  it's  physical  egpearanoe  and  it's  performanoe  in  terms  of  an 
operating  system  acting  as  a  ftamework  far  some  particular  application.  The 
document  which  describes  the  system. 

data  base 

A  doaanait  which  deteuls  the  system's  application  in  terns  of  signals 
and  data,  their  collection,  cxxmecticn,  tranemissicn,  processing  and 
di^lay.  The  definition  of  what  they  are  rather  than  how  they  are  to  be 
processed.  The  definition  of  vhat  is  normal  and  what  is  not;  the  definition 
of  the  relationships  between  voltages,  currents  and  pressureB,  tcspeiatures. 
The  docaanent  which  describes  the  boundary  between  the  systan  and  the  outside 
(ship)  world. 
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operational  s^jeclflcatlon 


A  document  vAuch  defines  «hat  the  eqpplicatlon  processing  does,  the 
definition  of  autcnatlc  seqjenoes  and  control  algorithms,  the  definition  of 
the  performanoe  of  the  system  as  far  as  the  operator  is  concerned. 

interface  definition  document 

A  documatt  whi<d\  relates  the  system  to  the  "real  world",  it's 
comection  to  the  other  systems  of  the  ship,  the  definition  of  vAiere  the 
signals  are  derived  emd  vhere  they  are  delivered  to.  Ihe  regnxping  of 
slgneds  under  identifiable  ship  system  names  (such  eis  main  engine,  ste^uig 
gear,  generators..)  end  the  guedlty  control  scheme  which  prohibits 
unoo-ordinated  changes,  and  hence  unauthcsrised  ch2U’)ges,  to  the  design  of 
plant  and  system  interfaiaes. 


DKse  four  tools  must  be  developed  in  parallel  as  the  design 
progresses.  Each  relies  on  the  others  for  it's  own  accurate  interpretaticn 
and  each  has  a  unique  value  to  those  vho  use  them.  liice  all  tools  they  must 
be  used  properly  and  those  responsible  for  them  shcxild  exercise  proper  ccune 
and  ipkeep;  terns  which  are  eynanyncus  with  good  gualily  axitrol. 

8.  DAHK3;  inuittNCE 

Damage  tolerance  is  an  essential  oonsicieraticn  in  a  system  as  cxnplex 
as  that  being  described.  Ibe  time  at  «hich  the  system  will  be  culled  on  to 
perform  in  anger  is  in  the  prqsaration  stage  prior  to  an  incident  (if 
adequate  warning  is  given)  and  the  pericsd  immediately  after  an  incident  in 
which  minor  system  damage  has  occurred  or  in  which  major  damage  has  been 
sustained  by  the  vessel. 

It  is  not  easy  or  advantageous  to  seperate  those  signals  and  data 
associated  with  damage  control  functions  from  the  shipwide  control  and 
surveillance  system.  Ihe  sheer  nunhers  of  signals  involved  cuid  the 
efficiency  euid  integrity  with  which  th^  may  be  handled  by  a  distributed 
ptuoessor  type  of  system  usually  means  there  is  no  real  practical 
alternative.  Exo^itlcns  to  this  are  made  in  prac:tise  such  as  signals 
asscKlated  with  fire  detection  and  gas  detection  systems  but  just  how  many 
of  these  syertems  have  redundcuxy  eoid  fault  tolerant  features  which  would 
ensure  their  cxntinued  operation  after  a  major  incident? 

There  are  slnple  rules  vhich  can  be  epplled  to  maximise  damage 
tolerance  and  these  relate  mainly  to  redundancy  and  separation.  This  not 
only  2^1ies  to  harhmre  in  the  general  sense  but  also  to  the  design  of 
cxxTtrol  schanes,  for  example,  those  which  use  multiple  signal  inputs.  In 
this  case  the  rule  is  to  ensure  that  ed.i  signals  in  the  same  cxxitrol  scheme 
are  cx>llec;ted  by  the  same  means.  The  situation  to  avoid  is  one  in  which  some 
signals  are  cabled  direct  to  the  procsessor  performing  the  control  action 
while  others  are  carried  over  a  data  bus.  The  result  of  not  heeding  this 


3.160 


rule  is  usually  the  need  for  qperator  interventlcn  at  local  level  in  the 
event  of  systen  type  failures  such  as  a  data  bus  fault. 


Ihere  is  2aso  the  possibility  of  tising  prcblesB.  under  normal 
operating  oonditicxis  with  the  sysbem  operating  oorrecrtly  2l11  data  will  be 
"current".  Die  definition  of  current  varies  fran  system  to  system  but  as  a 
guide  this  will  mean  sanpled  data  will  vary  in  age  from  about  O  to  3  seconds 
and  seijfloe  up  to  5  or  6  seconds  for  processed  data.  Timing  difficulties  can 
arise  vhen  control  algarithms  do  not,  at  can  not,  take  aooount  of  varying 
time  delays  in  received  data.  In  a  damage  situation  data  vpdate  may  not 
occur  on  a  significant  nmber  of  dnamels  for  a  relatively  long  period.  On 
some  systems  "old"  data  can  exist  without  tpdate  indefinitely  -  whmi  this 
oocuis  ocninand  signals  are  usually  affected  too  and  nay  resi^  in  a  system 
waiting  for  tr2>nsmissicn  at  sane  later  date.  If  all  the  data  required  by  a 
control  algorithm  are  relayed  in  the  sane  way  iltere  is  at  least  a  chance  of 
this  peurt  of  the  scheme  failing  in  an  orderly  fashion. 

The  system  f2dlure  mode  in  a  damage  situation  can  not  be  pfcedicted 
therefore  due  regard  needs  to  be  paid  to  the  role  vhich  the  system  will  be 
expected  to  play  in  ensuring  S2ife  nanetgement  of  the  vessel  if  the  worst 
happens.  The  control  and  surveillance  system  oust  sipport  personnel  in  the 
follcwing  way. 

VBiile  everything  is  relatively  normal  the  system  should  sipport  rcpid 
assessment  of  the  ships  present  condition,  rspid  attairroent  of  the  desired 
ships  condition  and  should  continue  monitoring  to  ensure  the  assessment  is 

ip  to  date. 

Hhen  damage  is  sustained  the  system  should  support  accurate  assessnant 
of  damage,  the  fomulation  and  ijqplemenCation  of  effective  measures  to 
minimise  the  effects  of  this  damage  and  subsequent  restoraticn  to  near 
normal  conditions  if  at  etll  possible.  The  system  should  thereafter  continue 
to  monitor  events  as  a  means  of  confirming  these  measures  are  effective. 

When  attegpting  to  carry  out  emergency  repairs  in  the  aftennath  of  a 
serious  incident  the  system  should  support  the  co-ordination  of  repair 
efforts  as  far  as  possible. 

The  principle  aim  should  be  to  gather  and  record  as  nuch  status 
information  as  passible  within  the  damage  headquarters  and  main  control 
areas  \diile  tlie  systan  is  miking  nonaally.  Damage  may  result  in  the 
severing  of  vited.  data  links  and  disparity  in  status  displays  in  different 
areas.  There  is  no  practical  systan  configuration  fdiicb  can  guarantee  this 
will  not  ooair.  The  systaa  can  only  provide  greatest  suppcat  under  nomal 
operating  oonditions. 

It  is  possible  to  arrange  that  isolatal  sections  of  the  ^rstan  continue 
to  operate  for  sufficient  time  to  edlow  the  most  lanoductive  enploymait  of 
manpoMer  in  the  period  lamediately  following  an  incldait,  but  this  time  is 
limited.  This  is  achieved  by  ensuring  indeperrtenoe  for  operatiow  by  design 
of  oontrol  euxanganents  and  sipport  services  such  as  power  supplies. 
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As  the  operating  situation  deterlofrates  the  systan  can  be  expee^xd  to 
degrade  and  other  means  of  reaordlng  and  dlqfHaying  status  infoxma^on  oust 
be  eB{d.ciyed,  for  example,  a  oagfcinatlon  of  verbal  reporting  and  manually 
vpdated  Information  boards.  Care  must  be  taken  to  ensure  degradation  Is  as 
graceful  as  possible  and  the  method  of  transfer  of  data  from  the  system 
di^d^V  devices  to  the  Informatlcn  boards  should  be  designed  for  ease  and 
accuracy. 

As  the  system  degrades  through  damage  it  beocmes  increasingly  iaportant 
to  ensure  that  the  displayed  information  is  eKxaxraite.  To  meet  this 
reguiresent  data  validation  technl^ies  must  be  employed.  Diere  may  also  be  a 
need  for  the  use  of  data  base  models  of  the  plant  with  seme  level  of 
inferenoe  so  that  the  best  picture  Is  oonstrreted  from  available  data.  This 
may  mean  that  data  be  tagged  according  to  it's  confidence  level  both  in 
terms  of  true  status  and  age. 

Some  of  these  techniques  can  he  found  alzeeKiy  in  service  in  proven 
applications.  One  exanple  is  dynamically  positioned  vessels.  The  automation 
is  usually  carried  cut  fay  a  system  of  dual  oemputers  using  position 
refermx:e  and  anvlrcnmental  data  to  control  propulsion  plant  and  so  enable 
the  vessel  to  maintain  station.  Data  validation  is  carried  cut  and  both 
oemputers  maintain  a  oonplete  model  of  the  data  and  vessel  characteristics 
so  that  in  the  event  of  a  oenputer  failure  control  reverts  to  the  second 
oomixiber  without  Interrvption  and  the  system  can  still  perform  for  a  time  on 
oonplete  loss  of  reference  data  by  reverting  to  the  model. 

9.  KR  THE  ITOIRE 

The  repidly  changing  technological  environment  in  which  we  work  will 
not  permit  a  relaxation  in  the  efforts  to  ensure  oonplex  control  and 
surveillance  systems  are  fit  for  purpose.  The  learning  curve  in  the 
explication  of  such  ^stons  seems  to  extend  ever  hl^ier  aheex)  of  us  no 
matter  how  much  eiperlenoe  we  seem  to  gather. 

There  is  no  dcubt  that  an  increase  in  power  and  capacity  for  such 
systems  will  occur  in  the  future.  The  limitations  of  existing  systems  are 
generally  associated  with  perfotTaanoe;  hew  nary  work  stations  can  be 
serviced  simutaneously,  hew  much  data  can  be  carried  and  processed. 
Perfomanoe  is  simply  a  measure  of  the  speed  at  tdiich  data  processing  is 
carried  oit.  The  more  data  and  the  more  processing,  the  slcmer  the  system 
operates.  The  most  critical  time  for  the  vessel,  when  the  system  is  required 
to  work  wlthcut  failure  or  delay,  aay  also  be  the  tiine  that  the  system  wrks 
at  the  limit  of  it's  capacity. 

As  processing  ^eed  increases  and  peripheral  devlise  opoods  are 
inenneased  to  match,  new  oppcmrtunitles  will  open  ip  for  these  systems.  The 
area  in  which  the  most  striking  changes  will  take  place  is,  we  feel,  in  the 
design  of  the  Mtl. 

SystemiB  of  the  future  will  bring  the  plant  clata  into  focus,  permitting 
many  more  background  prooeesing  activltiee  to  be  performed  in  real  time. 
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ttieretDy  presenting  the  operatcra  with  Beny  aore  c{:pcoctunitles  for  developing 
and  testing  cxxitrol  strategies.  Hhe  operator  will  no  longer  have  to  resteiot 
his  eK±ivities  to  the  nuidane  task  of  plant  operation  per  se  but  will  adopt 
a  new  role  almnst  akin  to  that  of  the  desi^t^  of  present  tines  vtao  strives 
to  optinise  the  perfatnanoe  of  the  ship  as  a  whole. 

It  is  difficult  to  predict  what  fom  the  new  Mil's  will  take  but  they 
will  oertednly  inoorpacate  much  more  processing  of  {dent  infamation  and 
will  not  only  provide  checks  on  the  accuracy  of  data  received  but  will 
support  the  operator  by  prioritising  dl^dayed  infamation.  Operator  actions 
would  be  baaed  on  reconnendations  generated  by  "intelligent”  stpervisory 
systems  integrated  in  the  MU  which  %«uld  sdso  check  the  operator  response. 

10.  OGNCIUSICNS 

Ensuring  fitness  for  purpose  of  distributed  processor  based  control  and 
surveillance  systems  regulres  good  foundation  work  at  the  initial  concept 
stage,  effective  comnunlcatlon  of  reguirements  and  an  overview  of  the  role 
of  the  system  in  terms  of  the  oonplete  project.  It  also  calls  for  a  sensible 
balance  betweei  end  user  e9g)ectatlons  and  the  constraints  inposed  by  a 
particular  eysbem  design. 

Obese  reguirements  are  no  different  to  those  for  any  ccsplex  system.  If 
they  are  igno^  it  nay  t#ell  result  a  perfect  wcaddng  ^stem  but  one  which 
is  unsuitable  for  the  explication.  Ohis  can  ocafinmise  both  safety  and 
perfonnanoe. 


Fitness  regulres  all  concerned  to  be  aware  of  the  purpose;  a  clear 
statement  of  reguirements  Including  a  consideration  of  the  operational 
ai^iects,  is  essential.  Personnel  ocntinulty  throughout  the  project  naintains 
a  sense  of  direction. 

One  of  the  key  considerations  is  that  this  type  of  system  is  not  a 
repl2Kstient  for  traditional  systems  of  indicators,  controls  and  dl^lays 
cabled  directly  to  the  plant.  It  is  an  alternative  and  it's  use  should  be 
restricted  to  those  explications  emd  in  those  eureas  to  which  it  is  best 
suited. 
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FIGURE  1. 

THE  SHIPWIDE  CONTROL  AND  SURVEILLANCE  SYSTEM  UTILISING  DISTRIBUTED 
PROCESSING  -  KEY  ELEMENTS. 


NOTE;^ 

THE  TRADITIONAL  CONTROL  AND  SURVEILLANCE  SYSTEM  COMPRISING  THE  KEY  ELEMENTS 
OF  PLANT  SIGNALS.  CABLE  AND  INSTRUMENT  PNEUMATIC  TRANSMISSION  SYSTEMS  AND 
CONTROLS  AND  INDICATING  DEVICES  IS  STILL  AN  ESSENTIAL  PART  OF  MODERN 
SHIPWIDE  SYSTEMS. 
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THE  USE  OF  A  MATHEMATICAL  MODEL  IN  A  TRACK  GUIDANCE  SYSTEM. 


by  Keitb  M  Miller,  Michael  J  Dove 
and  John  Chudley. 

Ship  Control  Group,  Polytechnic  South  West,  Plymouth,  United  Kingdom 


1.  ABSTRACT 

This  paper  describes  part  of  an  ongoing  research  program  in  automatic  navigation 
and  track  guidance.  In  particular  it  looks  at  efforts  to  improve  the  accuracy  of  the 
mathematical  model  used  in  an  integrated  stystem  which  is  to  be  used  for  navigation, 
guidance  and  collision  avoidance.  The  paper  commences  with  a  brief  description  of  the 
mathematical  model  and  the  state  space  equations  developed  from  it.  There  then  follows  a 
description  of  the  Kalman -Bucy  filter  being  developed  for  use  in  a  marine  navigation  system, 
together  with  the  problems  of  accurately  modelling  a  vessel  in  changing  circumstances,  when 
these  circumstances  affect  the  hydrodynamic  coefficients  upon  which  the  model  is  based.  It 
is  then  suggested  that  the  accuracy  of  the  model  and  indeed  the  inputs  to  it,  which  must 
be  the  same  as  the  inputs  to  the  actual  system,  are  paramount  to  the  use  of  filtering 
techniques  in  marine  navigation.  To  overcome  the  problems  of  updating  the  model  under 
operational  conditions  system  identification  techniques  are  introduced.  This  is  achieved  by 
augmenting  the  state  vector  by  including  sway  and  yaw  coefficients  derived  from  the 
hydrodynamic  coefficients.  This,  in  turn,  involves  extending  the  matix  which  represents  the 
ship,  but  simplification  methods  are  then  introduced  to  reduce  the  computation  times  in  the 
micro-processor  based  system  used  in  the  trials  vessel.  The  paper  goes  on  to  explain  the 
complete  navigation  and  track  guidance  system,  and  concludes  by  discussing  some  of  the 
results  obtained,  particularly  where  the  technique  has  resulted  in  improvements  in 
navigational  accuracy. 

2.  INTRODUCTION 

Chudley  et  al  C1]  formulate  a  mathmatical  model  and  outline  an  application  in  marine 
simulation.  Similiar  models  can  be  used  to  improve  navigation  of  a  vessel  at  sea,  or  perhaps 
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more  importantly,  while  operating  in  confined  waters;  if  this  leads  to  improved  accuracy  of 
navigation  it  increases  the  safety  margins  of  shipping  using  narrow  channels  and  port 
approaches.  Research  at  Polytechnic  South  West  has  been  concerned  with  integration  of 
navigation  data  with  mathematical  models  using  Kalman  filtering  techniques,  a  technique 
which  is  already  established  in  the  aerospace  industries,  and  in  some  specialised  maritime 
applications  such  as  dynamic  positioning  systems  where  navigational  accuracy  requirements 
dictate  the  need  for  precise  measurements.  For  the  average  merchant  vessel  however, 
carrying  typically  less  accurate  systems  giving  a  position  fix  with  a  random  error  of  between 
100  metres  and  1  kilometre,  forward  speed  through  the  water  with  a  random  error  of  0.1 
knots,  and  a  heading  to  the  nearest  degree,  improvements  to  navigation  accuracy  through 
integration  are  not  so  readily  available,  and  may  not  be  necessary.  Work  by  Kalman  and 
Bucy  C21  targeted  at  the  aerospace  industry,  showed  how  independant  estimates  of  the 
state  of  a  system  can  be  combined  to  give  the  most  probable ,  or  minimum  variance, 
estimate.  This  terminolgy  implies  a  statistical  inference,  indeed  the  process  assumes  that 
random  errors  within  the  measurement  systems  are  Gaussian  and  the  standard  deviations 
known.  Dove  [33  demonstrates  the  application  of  Kalman  filtering  to  marine  navigation, 
combining  state  estimates  from  measurements  with  those  from  a  mathematical  model.  Trials 
conducted  in  simulation  show  promising  results.  In  this  work,  however  the  model  used  to 
represent  the  vessel  is  also  used  within  the  filter.  Any  deviation  between  the  two,  or 
inclusion  of  an  external  forcing  function,  may  lead  the  optimal  estimate  to  stray  from  the 
true  value.  This  suspicion  was  confirmed  by  tests  conducted  using  data  collected  on  board  a 
vessel  in  the  Solent  (UK)  C43.  Later  studies  directed  towards  overcoming  these  difficulties 
have  included  afloat  trials  in  the  Polytechnic’s  catamaran  and  current  work  involves  the  use 
of  a  2000  tonne  vessel  engaged  in  the  European  coastal  trade.  The  ship  model  which  forms 
an  integral  part  of  the  Kalman  filter,  and  hence  a  part  of  the  overall  track  guidance  system, 
is  formulated  in  three  degrees  of  freedom.  Central  to  the  goodness  of  the  model  is  the 
derivation  of  a  set  of  coefficients  which  describe  the  motion  of  the  vessel  under 
consideration. 

3.  THE  MATHEMATICAL  MODEL 

The  model  used  in  this  investigation  is  based  upon  a  Eulerian  set  of  equations  of 
motion.  The  forces  and  moments  are  derived  in  the  usual  way.  as  originally  given  by 
Abkowitz  C53,  with  a  modular  approach  as  presented  by  Tapp  [63  for  use  in  marine 
simulation.  Forces  and  moments  are  decomposed  into  contributions  associated  with  the 
system  elements,  for  example  hull,  propeller,  rudder  and  disturbance  terms.  X  and  Y  are 
the  forces  of  surge  and  sway  and  N  is  the  yaw  moment,  x,  y  and  41  are  Ihe  corresponding 
displacements  of  the  vessel  and  u,  v  and  r  are  their  derivatives  The  rudder  angle  is 
denoted  by  S,  the  propeller  revolutions  by  n  and  the  vessel  moves  on  a  grid  (xo.y,)  defined 
on  the  earths  surface,  where  x,  is  the  direction  of  true  North,  giving  a  reference  from 
which  heading  (i}))  is  measured. 
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In  order  to  model  the  behavior  of  the  hull  it  was  first  necessary  to  evaluate  the 
derivatives  used  in  the  equations  of  motion.  These  hull  constants  are  termed  hydrodynamic 
coefficients  and  are  usually  obtained  by  conducting  controlled  tests  on  a  scale  model  in  a 
towing  tank.  Full-scale  trials  can  be  performed,  but  satisfactory  control  of  the  trials  is 
difficult  due  to  unknown  forces  such  as  wind,  tide  and  current  acting  on  the  vessel  and 
these  results  are  more  frequently  used  to  validate  the  coefficients  obtained  from  model 
tests.  There  are  also  some  theoretical  methods  available  for  coefficient  evaluation. 
Korvin-Kroukovsky  C7D  developed  a  method  whereby  the  vessel's  length  is  divided  into  strips; 
each  strip  is  then  treated  as  a  buoyant  cylinder  of  equal  area,  a  form  which  has  been  well 
researched  and  coefficients  established.  Integration  along  the  length  of  the  vessel  then  gives 
some  of  the  coefficients,  originally  those  in  heave,  pitch  and  roll.  The  technique  has  been 
extended  by  Clarke  C8]  to  include  sway  and  yaw.  This  method  is  widely  used  by  those 
concerned  with  ship  handling,  an  application  in  which  operators  are  not  concerned  with  cycle 
time  of  the  program,  whereas  one  of  the  constraints  of  filtering  is  that  the  model  must  run 
in  real  time  with  a  rapid  update  rate.  This  is  particularly  critical  as  the  filtering  theory  used 
to  date  assumes  that  the  system  is  linear  between  sampling  intervals.  Clarke  C8]  has 
evaluated  sway  and  yaw  coefficients  for  a  numtoer  of  vessels  using  towing  tank  and  rotating 
arm  test  data  and  then,  by  regression  analysis,  produced  formulae  for  evaluation  of  the 
linear  coefficients  directly  from  vessel  dimensions  of  length,  beam,  displacement  and  block 
coefficient. 

4.  THE  STATE  EQUATIONS 

Addition  of  first  order  differential  equations  to  represent  the  steering  gear  and  main 
propulsion,  followed  by  rearrangement  of  equations  of  motion  such  that  u,  v  and  r  are 

expressed  in  their  canonical  form,  yields  equation  set  (1).  X, . X  g,  Y.| . Yg ,  and  N., . Ng 

are  derived  from  the  vessel's  hydrodynamic  coefficients. 


■-1 

Y, 

0 

0 

0 

0 

0 

0 

0 

-1 

T. 

0 

0 

-1 

T, 

0 

0 

0 

0 

0 

0 

0 

-1 

T. 

X 

0 

0 

0 

1 

0 

0 

0 

0 

X 

0 

0 

Li 

X, 

X, 

0 

X. 

0 

X. 

0 

X. 

u 

0 

0 

y 

0 

0 

0 

0 

0 

1 

0 

0 

y 

+ 

0 

0 

V 

Y, 

0 

0 

Y, 

0 

X. 

0 

Y. 

V 

0 

0 

0 

0 

0 

0 

0 

0 

0 

1 

0 

0 

r 

N, 

0 

0 

N. 

0 

N. 

0 

r 

0 

0 

3.169 


The  eight  first  order  differential  equations  are  used  to  define  the  ship  and  can  be 
can  be  written  in  matrx  form  as 

i(t)  =  F(t)x(t)  ♦  G(t)u(t)  (2) 

where  f  is  the  continuous  time  system  matrix  representing  the  ship.  When  tide,  wind  and 
current  have  to  be  considered  it  is  convenient  to  partition  the  forcing  matrix  G  into  the 
control  and  disturbance  forcing  functions  G^  and  G^,  giving 

x(t)  =  F(t)x(t)  +  G<.(t)u(t)  ♦  Go(t)w(t)  (3) 

where  x(t)  is  the  state  vector,  u(t)  is  the  control  vector,  and  w(t)  is  the  vector  of 
disturbances.  Integration  of  equation  (3)  yields  the  corresponding  discrete  solution 

x(k+1)  =  A(k.k+I)x(k)  ♦  B(k,k+1)u(k)  ♦  C(k.k+1)w(k)  (4) 

where  the  matrices  A,  B  and  C  can  be  obtained  from: 

A(k,k+1)  = 

B(k,k+1  )  =  -  I  )F(t)"  G^(t)  (5) 

C(k.k+1)  =  -  I  )F(t>"  G„(t) 

5.  A  FILTER  FOR  MARINE  NAVIGATION  AND  GUIDANCE 

While  the  vessel's  position  is  of  primary  importance  for  marine  navigation,  the  state 
of  the  vessel  is  likely  to  be  passed  to  a  control  algorithm  for  track  keeping.  Further 
requirements  thus  comprise  accurate  heading  to  maintain  course,  and  velocity  information 
for  feedback,  or  damping,  of  the  control  loop.  The  system  process  for  the  vessel  described 
in  equation  (1)  is  tailored  to  suit  these  additional  requirements.  The  system  is  not  driven  by 
white  noise  but  by  a  deterministic  c<x»trol  vector  and  noisy  disturbances.  Control  is  assumed 
to  be  stable  and  disturbances  are  taken  as  Gaussian  processes  with  a  non  zero  mean. 

The  theory  of  the  Kalman-Bucy  filter  is  well  established  and  the  equations  used  in  the 
research  described  in  this  paper  are  given  by  Miller  C103.  The  filter  used  in  the  marine 
navigation  problem  is  an  extended  Kalman  filter.  That  is  the  non-linear  system  process  is 
linearized  about  the  most  recent  optimal  estimate,  while  the  measurement  process  is  linear 
and  the  errors  are  Gaussian.  As  a  ship  constitutes  a  non-linear  system,  when  parameters 
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such  as  large  alterations  of  course  and/or  speed,  shallow  water  effects,  and  trim  are 
considered  there  must  be  some  limitation  to  the  technique.  The  linearization  process 
assumes  constant  course  and  speed  during  each  sample  period.  This  is  reasonable  provided 
sample  times  are  small  when  compared  with  such  factors  as  ship  time  constants  and  time 
between  waypoints.  A  block  diagram  of  the  filter  is  shown  in  figure  1.  The  filter  quations 
are  used  recursively  to  obtain  the  state  estimate  at  a  future  sampling . 


x(k/k) 


Figure  1.  Block  Diagram  of  the  Optimal  Filter. 


Improvements  can  be  made  to  the  speed  of  the  filter  algorithm  by  considering  the 
manner  in  which  the  equations  are  used.  Figure  2  shows  an  iterative  loop  which  commences 
each  cycle  by  taking  a  measurement,  initiates  the  covariance  to  the  identity,  then  computes 
the  Kalman  gain  and  its  error  covariance.  The  iterations  are  used  to  obtain  convergence  of 
the  filter.  An  improvement  on  this  technique  can  be  made  by  changing  the  order  of  these 
operations.  In  practice  the  system  error  covariance  and  Kalman  gain  can  be  computed  prior 
to  performing  the  measurement  process.  During  this  time  the  computer  may  well  be  idling, 
while  awaiting  the  signal  to  initiate  the  measurement  cycle,  so  a  saving  may  be  made  in 
computer  time.  Furthermore,  by  computing  ^  initial  error  covariance  less  iterations  may  be 
required. 
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Figure  2.  The  Kalman  Filter  Loop. 

6.  SYSTEM  IDENTIFICATION 

Much  has  been  written  of  the  difficulties  of  obtaining  an  accurate  mathematical  model 
of  a  ship.  Experience  has  shown  however  that  a  good  mathematical  model  is  required  in  a 
maritime  optimal  track  guidance  system,  and  the  accuracy  of  the  filter  is  still  further 
improved  if  it  acquires  both  control  and  disturbance  inputs,  even  though  the  disturbance 
inputs  may  only  be  estimate  of  the  true  values.  There  is  the  additional  problem  of  changing 
hydrodynamic  coefficients  as  circumstances  change.  For  example,  as  the  underwater  surface 
of  the  hull  is  fouled  with  growth ,  when  the  vesel  enters  shallow  water  after  an  oceanic 
passage,  or  when  the  velocity  is  changed.  This  means  that  the  X,  Y,  and  N  values  in  the 
system  matrix  will  require  updating.  This  may  be  difficult  during  routine  commercial 
operations.  It  certainly  would  do  little  to  enhance  the  sale  of  a  filter  based  integrated 
navigation  system  if  the  potential  owner  were  informed  that  the  vessel  would  have  to  be 
periodically  taken  out  of  service  to  update  the  model.  Established  techniques  for  parameter 
identification,  based  upon  various  optimization  criteria,  would  require  new  algorithms  to  be 
li'.cluded  into  the  Kalman  filter  recursive  loop.  These  methods  are  usually  time 
consuming  and  consequently  are  unsuitable  for  real-time  applications.  However  Gelb  (11) 
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proposes  a  method  which  can  be  easily  implemented  into  the  existing  Kalman  filter  loop.  This 
method  has  been  applied  to  the  track  guidance  system  under  development,  optimizing 
parameters  on  the  minimum  variance  estimation  algorithms  already  in  use. 

6.1  Augmenting  the  State  Vector 

Let  the  unknown  parameters  be  denoted  by  a  vector  a,  having  dynamics  defined  by 
the  differential  equation: 

i  =  0  (6) 

with  non-linear  equations  of  motion,  the  system  process  can  now  be  written: 

X  =  f(x,a)  +  Gu  (7) 

where  both  a  and  x  are  to  be  estimated  from  the  noisy  measurement  data.  Combining  x 
and  a  into  a  composite  state  vector  denoted  x*  such  that: 


and  applying  this  system  process  to  the  extended  Kalman  filter  routine  yields  estimates  for 
both  states  and  unknown  parameters. 

6.2  The  Modelling  Process 

Selecting  the  vector  a  to  contain  hydrodynamic  coefficients  for  the  vessel  gives  a 
large  dimension  augmented  state  vector  and  a  large  transition  matrix.  This  formulation  would 
then  lead  to  cumbersome  computations,  defeating  one  of  the  prime  objectives  of  this 
research.  Furthermore,  due  to  cross  coupling,  some  coefficients  cannot  be  isolated  and  are 
therefore  unidentifiable.  An  alternative  method  was  suggested  by  Robbins  [12]  who  applied 
this  method  of  parameter  identification  to  aircraft,  but  used  simplified  mathematical  models. 
To  perform  the  Identification  process  the  system  process  was  reduced  to  smaller 
components  and  controlled  manoeuvres  were  performed.  Then,  assuming  certain 
cross-coupling  terms  to  be  negligible  under  the  control  applied,  for  example  when  applying 
rudder  to  the  aircraft  surge  and  sway  terms  only  are  considered  and  the  induced  roll  is 
neglected,  a  small  number  of  parameters  can  be  identified  from  each  manoeuvre. 
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It  is  not  economically  viable  to  attempt  to  identify  slowly  varying  parameters  while  on 
a  voyage  as  the  vessel  may  be  delayed  at  great  expense  during  identification  manoeuvres. 
Furthermore,  in  order  to  keep  the  dimensions  of  the  augmented  state  vector  to  minimum, 
maintain  identifiability  of  parameters  and  to  retain  sparse  population  of  the  transition  matrix 
it  is  necessary  to  identify  the  components  of  the  latter  directly.  Initially  only  sway  and  yaw 
terms  are  considered,  as  these  use  the  least  accurate  coefficients  and  were  seen  to  give 
poorer  results  than  the  surge  term.  The  augmented  state  vector  can  be  written  as: 


x»=  {  S,  n,  X,  u,  y,  v,  (}),  r,  Y„  Y.,  Y.,  Y,,  N„  N.,  N,,  N.  )’ 


(9) 


where  the  augmented  parameters  are  shown  in  equation  (1).  These  constants  are  dependent 
on  the  vessel  states,  and  hence,  assuming  a  slow  transition  time  of  the  vessel  in 
comparison  to  cycle  time  of  the  Kalman  recursive  loop,  the  parameters  to  be  identified  may 
be  taken  as  having  dynamics  given  by  equation  (6).  The  state  transition  matrix  F*  is  now  of 
dimension  16  x  16,  as  shown  in  equation  (10). 
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where  0,  is  the  zero  matrix  of  dimensions  8x8. 

Writing  this  as  a  partitioned  mo',  x  of  4  sub-matrices,  each  of  8x8  dimension: 
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The  original  8  states  of  the  system  process  are  still  described  by  equation  (1).  The 
discrete  transition  matrix  is  then  given  in  partitioned  form  by: 


(12) 


where  I,  is  the  identity  matrix  of  order  8.  and  A  is  the  discrete  solution  to  F . 

6.3  The  Measurement  Process 

The  original  eight  states  of  the  measurement  vector  can  be  obtained  as  before  but 
the  augmented  states  are  not  measured.  Y,.  Y„  Y,.  Y,,  N,,  N,  and  N,  can  be  obtained 
from  the  previous  optimal  estimates.  The  revious  set  of  vaiues  for  the  sway  and  yaw 
coefficients  are  used  in  an  iterative  manner  to  obtain  new  values  as  given  in  equation  set 
(13a).  Solutions  for  the  equations  should  be  iterated  to  obtain  convergence. 
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-  -Y.^  -  Y,v  -  Y,r 


Y  =  -Y'S  -  Y.u  -  Y.r 


Y.  = 


N,  = 


~Y,S  -  Y,u  -  Y.v 


-N4U  -  N,v  -  N,  r 


(13a) 


_-N,S  -  N.v  -  N,r 


N  -  N,u  ~  N,r 


-N,5  -  N,u  -  N.v 
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The  measurement  matrix  can  thus  be  written 


where  X  is  an  8  x  8  diagonal  matrix  with  diagonal  elements  equal  to  the  corresponding 
elements  of  the  state  vector.  Then  for  the  computation  of  the  Kalman  filter  gain: 


The  filter  must  be  modified  to  account  for  the  additional  terms  included  in  the 
processes  above.  In  order  to  estimate  the  prediction  error  covariance  and  hence  the  Kalman 
gain,  A*  should  incorporate  the  entire  matrix  F*: 


The  matrix  0  can  then  be  obtained  in  a  similar  way  to  the  discrete  control  and  disturbance 
matrices  and  is  then  given  by: 


D  =  -  I  )F(t)  ’E 


(15) 
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The  Kalman  gain  matrix,  which  now  has  dimensions  16x16,  is  computed  as  shown  by  Gelb 
[11], 


7,  CONTROL  AND  GUIDANCE 

The  theory  of  an  optimal  multi-variable  control  system  has  been  developed  to  control 
simultaneously  position  and  velocity  of  the  vessel,  and  tested  in  simulation  by  Burns  [13]. 
Deviation  from  the  desired  values  were  corrected  by  operation  of  the  rudders  and  main 
engines.  The  cost  function  (J)  is  based  upon  the  summation  of  the  weighted  errors  over 
some  time  interval,  perhaps  over  one  stage  of  the  voyage.  In  addition  to  minimise  the  errors 
in  the  output  parameters,  the  optimal  controller  must  also  attempt  to  minimise  the  control 
effort,  that  is  to  minimise  rudder  and  main  engine  activity.  The  cost  function  is  normally 
stated  in  the  following  quadratic  terms; 


where  r  is  the  desired  state  vector  and  Q  and  R  are  usually  diagonal  matrices,  with  the 
values  of  the  individual  elements  reflecting  the  importance  of  the  parameters  being 
controlled. 


Disturbances 

w(k+1) 


Noise 

v(k+1) 


Noise 

Statistics 


r(kT1) 

Desired  state 


Vessels  position 
on  the  grid  to 
drive  displays, 

plotters  etc. 


COORDINATE 
TRANSFORMATION ; 

Spheroidal 

data 


Figure  3,  The  Complete  Integrated  Navigation  and  Control  System 


3.177 


An  initial  requirement  of  the  controller  is  the  desired  state  r  at  each  sample  time. 
This  is  obtained  by  entering  a  series  of  waypoints  into  the  computer.  In  practice  waypoint 
position  is  entered  through  the  keyboard  using  either  a  cursor  on  the  chart  display  driven  by 
the  arrow  keys,  or  by  typing  in  co-ordinates  using  the  alpha-numeric  keys.  The  program 
assumes  that  each  pair  of  waypoints  alternately  define  a  straight  line  followed  by  a  curve. 
Thus  taking  the  first  waypoint  as  the  starting  point,  the  second  is  the  "wheel  over"  position 
at  the  start  of  the  arc  required  to  reach  waypoint  three.  On  reaching  this  point,  the  vessel 
is  required  to  be  on  a  steady  course  to  waypoint  four  which  is  the  next  "wheel  over" 

position  and  so  on.  With  each  waypoint  either  a  speed  for  that  leg  of  the  passage  or  an 

estimated  time  of  arrival  is  entered,  so  the  desired  state  of  the  vessel  can  be  computed  at 

each  sample  time  prior  to  starting  the  voyage.  The  overall  integrated  navigation  system  is 

shown  as  a  block  diagram  in  figure  (3) 

8.  RESULTS  AND  CONCLUSIONS 

Data  sets  used  in  earlier  work  were  rerun  using  the  filter  algorithm  with  system 
identification.  The  overall  track  plot  for  a  passage  in  to  Plymouth  showed  a  significant 
improvement.  Part  of  a  typical  plot  is  shown  in  figure  (4),  from  which  it  can  be  seen  that 
the  filtered  track  follows  closely  the  true  position  of  the  vessel.  Figures  5  and  6  show  the 
identified  system  coefficients.  The  rudder  terms  Y,  and  N,  are  seen  to  be  noisy.  These 
terms  would  be  expected  to  reduce  to  zero  when  travelling  in  a  straight  line  and  increase 
during  the  use  of  rudders  in  a  turn,  which  is  seen  to  occur,  further  noise  is  probably  due 
to  noisy  rudder  measurements.  Y,  and  N,,  the  surge  terms  are  close  to  zero.  These  terms 
influence  the  turning  characteristics  with  speed  and  over  the  6  to  7  knot  speed  range  used 
during  the  trial  have  little  influence. 


Figure  4.  Comparison  of  Measured.  Filtered  and  True  Positions. 
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Figure  5.  Sway  System  Coefficients. 
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Figure  6.  Yaw  System  Coefficient^. 
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A  technique  to  overcome  coefficient  inaccuracies  and  variations  by  incorporating  them 
in  to  the  state  vector  has  been  introduced.  Trials  were  undertaken  for  sway  and  yaw  terms 
only  as  these  were  considered  to  be  the  most  inaccurate  and  widely  varying,  but  the  method 
can  also  be  applied  to  the  surge  terms.  Trials  to  this  end  are  now  being  undertaken. 
Resulting  track  plots  of  filtered  position  showed  the  vessel  to  remain  within  20  metres  of 
the  demanded  track.  The  filtering  algorithm  in  use  is  intended  to  cope  with  random  errors 
only,  and  fixed  errors  must  be  evaluated  and  either  removed  prior  to  filtering,  or  an 
allowance  must  be  made  for  them.  In  this  way  the  noise  reduction  achieved  is  a  better 
assessment  of  performance.  The  ability  of  the  system  to  maintain  a  position  central  to  the 
noise  of  the  position  fixing  system,  in  this  case  a  Decca  Navigator  was  used  because  it 
gave  the  best  coverage  of  the  approaches  to  Plymouth  at  the  time  the  trials  were 
undertaken  ,  demonstrated  that  the  filter  was  producing  accurate  outputs  of  displacement  in 
the  three  degrees  of  freedom  considered.  It  was  shown  previously  CM]  that  inaccuracy  in 
one,  or  all,  of  these  outputs  led  to  drift  from  true  track.  As  values  for  velocity  are  fed 
back  into  the  modelling  process,  any  inaccuracy  in  their  estimates  leads  to  cumulative  errors 
in  the  displacement  outputs.  The  turn  rate  does  however  remain  noisy  and  an  improvement 
could  be  achieved  by  the  use  of  a  gyro  input,  which  was  not  available  in  the  test  vessel. 
Finally  the  filtered  output  was  fed  to  a  control  algorithm.  Optimal  control  theory  was  used 
to  establish  the  control  parameters  to  maintain  the  vessel  on  track,  in  both  along-track  and 
across-track  directions. 
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1.  ABSTRACT 

The  neural  network  controller  for  the  berthing  problem  of  the  ship  is  discussed  in 
this  paper.  The  three-layered  neural  network  is  used  to  shape  the  controller  and  the 
weights  and  threshold  of  each  unit  are  determined  by  the  error  back  propagation 
algorithm  with  the  prc-obiained  teaching  data.  The  controller  has  two  neural  net¬ 
works  which  are  used  in  near  and  far  fields  respectively,  based  on  the  precision  re¬ 
quired  in  each  field.  The  controller  is  presented  on  the  personal  computer,  and 

simulations  to  examine  the  performance  are  made  on  it.  In  spite  of  many  theoreti¬ 
cally  inarticulate  particulars,  simulations  show  the  prospective  capability  for  the 
berthing  control. 


2.  INTRODUCTION 

The  berthing  is  one  of  the  most  difficult  manipulation  of  the  ship.  As  the  speed  is 
small  and  disturbance  due  to  winds  and  currents  become  relatively  big.  control  de¬ 
vices  are  not  so  effective  any  more.  However,  very  precise  control  is  necessary  es¬ 
pecially  for  not  colliding  the  ship  to  the  berth.  As  the  ship  motion  and  control  ef¬ 
fectiveness  is  very  difficult  to  represent  in  terms  of  the  differential  equation,  the 
conventional  design  method  for  the  feedback  controller  is  not  easily  applicable  for 
this  problem^'^. 

In  spite  of  difficulties,  the  human  operator  is  very  successful  to  make  a  safe 
berthing.  The  captain  determines  the  control  outputs  to  the  ship  by  processing  data 
such  as  the  velocity,  acceleration,  distance  between  ship  and  berth,  winds,  currents, 
environmental  restrictions  and  others  as  input.  It  could  be  expressed  as  the  very 
complicated  input-output  relation  between  ship's  slate  and  the  applicable  control. 
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Recently,  the  neural  network  is  applied  to  various  kinds  of  engineering  problems 
In  the  field  of  the  letter  recognition,  the  neural  network  gives  good  results.  The 

neural  network  provides  a  letter  according  to  the  pattern.  Similarly,  the  ship's  slate 
is  taken  into  the  neural  network  controller  as  a  pattern,  and  the  network  provides 
the  control.  The  network  makes  a  device  to  change  the  state  into  control  which  is 

made  by  the  human  operator  at  present. 

In  this  paper,  the  neural  network  berthing  controller  for  the  154,000-ton  tanker  i 
presented.  Although  there  are  several  applications  (2-5)  ihg  neural  network  to 
the  ship  control,  it  has  not  been  applied  to  the  berthing  problem.  The  neural  net¬ 
work  used  here  is  still  primitive  and  only  the  basie  berthing  patterns  are  illustrated. 
However,  the  simulation  shows  the  prospective  ability  of  the  neural  controller  for 
the  berthing. 

3.  THE  BERTHING  AND  THE  NEURAL  NETWORK<6'  2) 

U _ The  berthing  procedure 

The  berthing  procedure  is  summarized  in  Figure  1.  The  ship  approaches  to  the 
berthing  spot  in  a  slow  approaching  speed.  The  ship  reduces  the  speed  and  changes 
the  course  first  by  rudder  and  later  by  side  thrusters.  The  ship  must  stop  at  the 
berthing  spot  with  almost  zero  position  and  heading  errors.  Actually,  the  lateral 
speed  should  be  small  enough  not  to  damage  both  the  ship  and  the  berth.  This  is  the 
most  typical  and  basic  control  for  the  berthing.  If  there  arc  winds  and  currents,  the 
control  would  be  more  complicated. 


Far  field; 


Figure  1.  Berthing  procedure. 


L2 _ The  neural  network 

_ Configuration  and  units.  The  typical  neural  network  is  shown  in  Figure  2(a). 

Of  course,  more  complicated  network  can  be  used.  The  input  is  a  state  of  the  ship  and 
output  is  the  control  for  the  ship.  The  neural  controller  gives  the  control  according 
to  the  state  of  the  ship.  Each  unit  has  its  own  input-output  characteristics  repre- 


3.184 


sented  by  weights  of  the  connection,  sj.  thresholds,  h,  and  transfer  function  as  shown 
in  Figure  2(b).  Input  to  the  unit  is  expressed  in  the  weighted  sum  of  the  inputs  from 
the  connected  upstream  units  and  the  threshold.  Output  signal  is  determined  by  the 
nonlinear  transfer  function  to  the  input.  Once  the  weights  and  thresholds  arc  de¬ 
termined,  the  neural  controller  provides  the  control  output  according  to  the  ship's 
state. 

h.  Learning.  Weights  and  thresholds  in  the  network  arc  determined  by  learning 
the  teaching  data.  Teaching  data  arc  carefully  collected  set  of  the  input-output  rela¬ 
tions  which  the  neural  network  should  follow.  Weights  and  thresholds  arc  deter¬ 
mined  to  minimize  the  error  defined  by  the  output  difference  between  the  teaching 
data  and  neural  network  output  to  the  same  input.  The  process  is  called  learning.  It 
is  not  necessary  to  learn  all  the  data  the  ship  may  face,  the  neural  controller  will 
have  the  ability  to  interpolate  or  extrapolate  if  it  has  learned  enough  data.  Some  al¬ 
gorithms  are  proposed  for  this  purpose,  the  error  back  propagation  is  applied  in  this 
paper.  The  error  back  propagation  is  an  iteration  method  similar  to  the  method  of 
the  steepest  descent  as  summarized  in  Figure  3.  The  error  is  defined  in  Equation  ( 1 ), 
Weight  increment  at  the  (p-rl)th  iteration  is  shown  in  Equation  (2).  The  weight  can 

be  obtained  from  the  output  layer  to  upstream  units.  If  the  type  and  size  of  the  net¬ 
work  and  teaching  data  arc  given,  the  procedure  to  shape  the  network  is  rather  clear. 
What  type  and  size  of  the  network,  what  the  teaching  data  should  be  are  the  biggest 
problems  to  be  solved.  They  should  be  determined  from  the  nature  of  the  problem 
and  precision  required  for  the  network.  There  is  no  advisable  guide  for  the  problem. 
In  this  paper,  simple  three-layered  network  is  used  and  the  size  of  the  network  is  de¬ 
termined  by  the  resolution  requirement  for  the  teaching  data  as  described  in  the 
following  section. 


Transfer  function. 


(a)  Three-layered  network. 


(b)  Mathematical  model  for  the  unit 
and  the  transfer  function. 


Figure  2.  The  neural  network. 
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EiTor  :  E  =  -j^(di-Oi)^  . (1) 

i 

Weight  inctement  at  the  (fH-i)  th  iteraiion  : 

aw]"'  f  (p+ l)  =  i,5‘o‘‘‘‘+aAW‘'‘  ](p)  . (2) 

Where 

5]  =(di- o.)  f  '  (i])  . (3) 

for  output  layer ,  and 

sr=[l,sj*‘w?;“]f'  (i‘)  . (4) 

for  middle  layer . 

Notations 

d,  ;  Teaching  data  of  i-th  unit  of  the  output  layer. 


Oj  :  Neural  network  output  i 'th  unit  of  tf>e  output  layer, 
ii  :  Neiiriit  network  input  of  i-th  unit  of  the  ou^ut  layer. 

w.^  *  :  Weight  of  connection  of  j-th  Unit  in  (k-l)  ih  layer  and  i- th  unit  in  k-th  layer. 

0  '  :  Output  of  the  ( k- 1 )  th  unit  of  j-th  layer, 

a  T\  :  Acceleration  factors, 
f  ,  f  Transfer  function  and  its  derivative. 


Figure  3.  The  error  back  propagation  algorithm. 

4.  THE  NEURAL  CONTROLLER  FOR  BERTHING 

in  this  section,  the  neural  controller  for  berthing  is  described, 

4J _ 154,000  ton  tanker 

The  neural  controller  for  the  154.000  ton  tanker  is  presented  in  this  paper,  as  the 
dynamics  of  the  type  ship  in  slow  speeds  were  obtained  in  detail  by  model  experi¬ 
ments  by  Kose  et  al^*).  The  principal  particulars  of  the  ship  is  summarized  in  Table  1, 
The  ship  has  bow  and  stem  thrusters  in  addition  to  the  propeller  and  the  rudder.  To 
describe  the  motion  of  the  ship  in  very  low  speeds,  many  mathematical  models  arc 
proposed.  In  this  paper,  the  mathematical  model  proposed  by  Kose  cl  al^*)  was  em¬ 
ployed.  The  detailed  discussion  on  the  equations  arc  described  in  APPENDIX. 

4.2 _ Composition  of  the  neural  controller 

a. - Phases  1  and  2.  The  area  where  the  neural  controller  works  is  shown  in  Figure 

4.  The  area  is  divided  into  far  and  near  fields  from  the  berth.  In  the  far  field  called 
Phase  1,  the  ship  is  controlled  by  the  propeller  and  the  rudder.  On  the  contrary,  in 
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Layers  :  Input  Hidden  Output 


Input  Hidden  Output 


Notations 

(  X  ,  y  ) :  position  of  the  ship,  H* ;  Heading  of  the  ship 
( u  ,  V ,  r ) ;  Linear  and  angular  speeds  with  respect  to  body  fixed  cords. 

( w  ,  d ) :  Wind  speed  and  direction.,  n  :  Propeller  rps. ,  6  ;  Rudder  deflection, 

bth  :  Bow  thruster  force. ,  sth  ;  Stem  thruster  force. 


Figure  5,  Configuration  of  the  neural  controller 

the  near  field  called  Phase  2,  two  side  thrusters  arc  mainly  used  and  supported  by  the 
propeller.  As  the  field  becomes  bigger,  the  error  at  the  berthing  spot  may  become 
bigger.  If  one  controller  is  used  in  whole  field,  a  big  network  may  be  necessary  to 
achieve  sufficient  accuracy.  However,  if  the  field  is  divided  into  two  parts,  two  mod¬ 
erate  sized  networks  will  suffice. 

b.  The  neural  controller.  The  thrcc-laycrcd  neural  network  is  used  as  shown  in 

Figure  5.  The  input  layer  includes  eight  units,  that  is,  the  position  of  the  ship,  x  and 
y,  the  heading,  y,  linear  and  angular  velocities,  u,  v  and  r.  speed  and  direction  of  the 
wind,  w  and  d.  As  for  the  output,  the  propeller  rps,  n.  the  rudder  deflection,  5,  for  the 
Phase  1,  the  propeller  rps,  n.  the  thrust  of  the  bow  and  side  thrusters,  bth.  sth  arc  for 
the  Phase  2, 

£.1 _ Hidden  layer  sizing.  Presently,  there  arc  no  instructive  guidelines  to  estimate 

how  many  hidden  units  are  necessary.  In  this  paper,  the  number  of  hidden  units  is 
determined  as  follows.  The  sigmoid  transfer  function  is  used  and  it  is  considered  con¬ 
tinuous  form  of  binary  function.  As  the  outputs  of  hidden  units  are  nearly  binary.  N 
hidden  units  can  represent  2^  different  patterns  in  the  hidden  layer.  Therefore  the 
number  of  hidden  units  which  can  distinguish  P  patterns  is  log2P.  The  maximal 
number  of  teaching  data  used  in  the  Phases  1  and  2  is  130.  The  number  of  the  rc- 
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quested  hidden  units  is  eight,  for  Iog2l30  =  7.02.  Ten  hidden  units  are  thought  to  be 
enough  in  both  Phases  I  and  2. 

4.3  Teaching  data 

Teaching  data  are  obtained  by  the  simulation  on  the  personal  computer  NEC  PC- 
9801  RX  with  using  the  simple  manual  controller.  The  manual  controller  was  con¬ 
nected  through  the  A/D  converter.  The  manual  controller  has  four  volumes  which 
correspond  with  the  propeller,  the  rudder,  and  two  side  thrusters.  One  of  authors 
made  teaching  data  by  himself. 

a.  Phase  1  teaching  data.  Figure  6  shows  the  Phase  I  teaching  data.  In  the  Phase 

1,  the  initial  velocity  is  fixed  5  kt,  and  no  wind  is  assumed.  Here  it  is  requested  that 

the  heading  of  the  ship  is  as  parallel  to  the  berth  as  possible,  and  the  velocity  is  about 
1  knot  when  the  ship  gets  into  the  Phase  2  in  order  to  achieve  a  good  control  in  Phase 

2.  The  time  history  of  No. 1-3  is  shown  in  Figure  6(b).  Circles  in  the  lime  history  and 
the  trace  show  the  points  where  the  teaching  data  is  obtained. 

b.  Pha.se  2  teaching  data.  Figures  7  and  8  show  the  teaching  data  for  the  Phase  2 

controller.  In  Figure  7,  the  traces  and  the  lime  history  of  No.2-6  leaching  data  arc 
shown.  The  initial  velocity  is  0  kt  in  Nos.2-1  to  2-3.  In  Nos.2-4  and  2-5,  the  ship 
started  from  the  same  positions,  but  the  initial  velocities  are  1  kt  in  No. 2-4  and  2  kt  in 
No.2-5.  No.2-6  and  2-7  start  from  the  same  point  with  initial  velocities  I  kt  and  2  kt 

respectively.  In  Figure  8,  teaching  data  concerning  the  wind  arc  shown.  The  wind 
speed  is  20m/sec  and  two  directions  arc  obtained.  Teaching  data  arc  basically  in  the 
constant  interval  in  time,  however,  data  arc  more  densely  obtained  near  the  points 
where  the  control  is  abruptly  changed.  Although  leaching  data  can  be  obtained,  it  is 

still  questionable  whether  the  quantity  and  quality  of  leaching  data  is  sufficient  or 

not  for  the  problem. 

Teaching  data  are  categorized  into  three  cases  as  shown  in  Tabic  2,  Case  1  is  for 
Phase  1,  and  Cases  2-A  and  2-B  are  for  Pha.se  2.  The  case  numbers  will  be  used  in  the 
discussion  in  the  next  section. 

4.4  Learning 

The  error  back  propagation  algorithm  is  used  here  for  learning,  and  the  main 
frame  computer  H1TA(2  M680/682  is  used  bccau.se  of  the  huge  number  of  iterations  in 
the  algorithm.  To  study  the  effect  of  the  number  of  hidden  units,  neural  networks 

with  10,  20  and  30  hidden  units  arc  examined.  As  a  result,  no  difference  in  terms  of 
the  convergence  error  are  observed  in  three  cases.  The  network  with  ten  hidden 
units  is  considered  sufficient  in  both  Pha.scs  I  and  2. 

5.  SIMULATION  RESULTS  AND  DISCUSSIONS 

5J _ Performance  of  the  neural  controller 

The  capability  of  the  neural  controller  is  shown  in  Figures  9(a)  and  (b).  The  net¬ 
work  was  composed  by  the  Cases  1  and  2-A  leaching  data  .  Wind  effect  is  not  taken 
into  account.  The  neural  controller  starts  from  the  point  A  and  ship’s  speed  is  5  kt. 
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(a)  Traces  of  teaching  data. 


Prop.(ips)  Rud.Cdeg) 


(b)  Time  history  of  the  No.  1-3  teaching  data. 
Figure  6.  Teaching  data  for  the  Phase  1  controller. 


(b)  Time  history  of  the  No.2-6  teaching  data. 


Figure  7. 


Teaching  data  for  the  Phase  2  controller. 


(a)  Traces  of  teaching  data. 


(b)  Time  history  of  the  No.3-1  teaching  data. 
Figure  8.  Teaching  data  concerning  the  wind. 
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Case  No. 

Te<k:hing  data  No. 

1 

1-1, 1-2, 1-3 

2-A 

2-1, 2-2. 2-3. 2-4. 2-5. 2-6, 2-7 

2-B 

2-1, 2-2, 2-3, 2-4. 2-5, 2-6, 2-7,  3-1,  3-2 

Table  2.  Cases  of  teaching  data. 


Indices  A  to  D  in  Figure  9  show  starting  point,  propeller  reverse,  phase  change  and 
berthing  point.  In  Figure  9(a),  initial  conditions  are  strictly  same  as  No.  1-3  teaching 
data.  In  Figure  9(b),  initial  conditions  are  between  Nos. 1-2  and  1-3  teaching  data. 

In  Figure  9(a),  it  is  rather  natural  for  the  ship  not  to  follow  the  exact  trace  of  the 
teaching  data  as  shown  in  Figure  6,  for  the  controller  has  been  composed  not  only  by 
No.  1-3  teaching  data  but  also  others. 

In  both  cases,  the  ship  goes  further  than  the  aimed  stopping  point.  This  may  be 
because  that  the  propeller  rating  is  increased  just  before  the  reverse  to  follow  the 
abrupt  change  of  the  propeller.  It  gives  unnecessary  speed  increase  for  the  ship.  If 
the  change  of  the  propeller  is  less  abrupt  or  smooth,  the  controller  may  be  more  suc¬ 
cessful  for  the  stopping  point  control.  Moreover,  it  is  experienced  that  the  increase 
in  propeller  rating  just  before  reverse  depends  on  how  the  teaching  point  was  se¬ 
lected  near  the  propeller  reverse  point.  In  general,  if  more  teaching  points  arc 
available  near  the  change,  the  less  increase  could  be  obtained  by  the  neural  con¬ 
troller. 

Figure  9(b)  shows  fairly  good  interpolation  capability  of  the  neural  controller. 

12 _ Wind  effect 

In  Figure  10(a)  and  (b),  the  control  capability  to  the  constant  wind  is  illustrated. 
The  wind  comes  from  45degrees  right  forward  in  the  simulation.  The  neural  con¬ 
troller  used  in  Figure  10(a)  learned  the  Case  2-B  teaching  data.  This  includes  the  ef¬ 
fect  of  the  20m/sec  wind  from  45degrecs  right  forward  and  right  rearward.  In  Fig¬ 
ure  10(b),  the  controller  was  composed  by  the  Case  2-A  data  which  excludes  the  wind 

In  Figure  10(a),  the  controller  is  .successful  to  lead  the  ship  to  the  berth.  The  wind 
gives  the  speed  toward  the  berth  and  side  thrusters  are  used  in  the  opposite  direction 
to  reduce  the  speed  by  the  wind.  In  Figure  10(b),  the  controller  cannot  take  the  wind 
effect  into  account  and  the  ship  collides  to  the  berth.  It  is  clearly  observed  that  the 
capability  varies  according  to  the  learning  data. 

Actually,  the  controller  used  in  Figure  10(a)  is  not  capable  to  manage  many  situa¬ 
tions,  for  it  was  made  only  by  two  wind  conditions.  There  should  be  much  more  wind 
cases  to  be  learned  for  the  controller  to  be  effective  also  to  the  wind. 

12 _ Extrapolation  capability 

The  neural  controller  has  a  certain  capability  of  the  interpolation.  The  interpola¬ 
tion  here  is  the  capability  to  form  the  control  between  teaching  data.  The  neural 
controller  may  have  capability  of  extrapolation  to  some  extent.  In  Figure  11.  the 
extrapolation  capability  was  examined.  In  this  case,  the  neural  controller  is  made  by 

Case  2-A  teaching  data  only  in  the  Phase  2  field.  In  Figure  11(a).  the  ship  starts  from 


i 
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(a)  Example  I  Initial  conditions  are  identical  with  teaching  data. 
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(b)  Example  2  General  case. 

Figure  9.  Control  by  the  neural  controller. 


(a)  With  learning. 
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Figure  10. 
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Without  learning. 

The  effect  of  the  wind. 
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a  little  outside  Phase  2  field  and  the  controller  also  starts  working  from  the  same 
point.  In  this  case,  the  controller  can  give  an  appropriate  control  for  the  ship.  In 
Figure  11(b),  the  starting  point  from  the  berth  is  twice  as  far  as  the  field  length  from 
the  berth.  In  this  case,  the  controller  is  not  successful.  As  shown  in  Figure  11.  the 
neural  controller  is  sometimes  successful  and  sometimes  unsuccessful  to  the  extrapo¬ 
lation.  It  is  not  clear  until  how  much  extent  the  extrapolation  is  available.  The 
control  by  the  extrapolation  is  not  reliable.  The  sufficient  quantity  of  teaching  data 
should  be  used  to  make  the  neural  controller  working  only  by  the  interpolation. 

6.  CONCLUDING  REMARKS 

The  three-layered  neural  controller  is  applied  to  the  berthing  problem.  Based  on 
the  accuracy  consideration,  two  neural  controllers  arc  used  in  far  and  near  fields  re¬ 
spectively.  The  neural  controller  at  present  can  provide  appropriate  control  for  the 

berthing.  The  effect  of  the  winds  and  currents  are  not  sufficiently  included  in  the 
present  controller. 

Several  discussions  on  the  inter-  and  extrapolations  arc  made.  The  neural  con¬ 
troller  has  a  capability  of  the  interpolation  and  it  can  be  furni.shcd  by  the  sufficient 
teaching  data.  On  the  contrary,  the  extrapolation  is  essentially  not  reliable.  The 
field  which  the  neural  controller  covers  should  be  included  in  the  interpolation  field. 

The  neural  controller  itself  has  very  complicated  nonlinear  input  and  output  rela¬ 
tions.  And  it  has  profound  ambiguity  such  as  the  size  and  type  of  the  network,  trans¬ 
fer  functions,  teaching  data  and  so  forth.  In  this  paper,  the  size  of  the  network  is 
determined  by  considering  the  number  of  patterns  to  be  distinguished. 

In  this  research,  the  applicability  of  the  neural  controller  is  shown  by  the  simula¬ 
tion  with  using  the  most  basic  prototype  neural  controller.  Both  the  mathematical 
investigations  and  the  application  development  by  trials  and  errors  of  the  network 
are  desired  to  give  a  design  method  of  the  neural  controller. 
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APPENDIX 


AJL _ Equations  and  coefficients 

Many  mathematical  models  of  the  ship  motion  have  ever  been  proposed.  In  this 
paper,  the  mathematical  model  proposed  by  Kose(*)  was  employed.  The  coordinates 
are  shown  in  Figure  A-1.  The  equations  are; 

(m+mx)u  =  (Xvr+niy)vr  +  Xuululu  +  Xwuv^/U  +  Xe 

(m+my)v  =  -mxur  +  YyUv  +  Tyvlvlv  +  Yrr  +  Y^rur  +  Yyvrv^ru/U^  +  Yyrrvr^/U  +  Yg 
(Izz  +  Jzz)f  =  Nuvuv  +  Nrr  +  Nrrrf^  +  Nyrur  +  NyyrV^r  +  Ng 


Xe  =  Xp  +  Xr  +  Xw 
Ye  =  Yr  +  Yt  +  Yw 
Ne  =  Nr  +  Nt  +  Nw 

m  Mass  of  the  ship. 

mx  .'  Added  mass  with  respect  to  the  x  axis. 

my  Added  mass  with  respect  to  the  y  axis. 

Izz  ■  Moment  of  inertia  with  respect  to  the  z  axis. 

Jzz  Added  moment  of  inertia  with  respect  to  the  z  axis. 

u,v  :  Velocities  with  respect  to  the  x  and  y  axes. 

U  :  Absolute  velocity. 

r  :  Angular  velocity  with  respect  to  the  z  axis. 

Xg.Yg  :  External  forces  with  respect  to  the  x  and  y  axes. 

Ng  :  External  moment  with  respect  to  the  z  axis. 

Xp  X-component  of  the  external  force  by  the  propeller. 

Xr.Yr.Nr  :  External  force  and  moment  components  by  the  rudder. 

Yt,Nt  ;  External  force  and  moment  components  by  side  thrusters. 

Xw.Yw.Nw  :  External  force  and  moment  components  by  the  wind. 

Forces  and  moments  by  propeller,  rudder  and  wind  arc  described  in  the  following. 
And  non-dimensionalized  coefficients  in  the  equations  are  shown  in  Table  A-1.  The 
non-dimensionalization  by  velocity  was  not  used  because  the  speed  becomes  almost  0 
at  the  berthing.  Here  the  gravitational  acceleration  and  Lpp  were  used. 

A-2  Thrust  generated  bv  propeller 

The  thrust  generated  by  propeller  is  given  by  these  equations  : 

J  =  vg/Dn 
Vg  =  v(l-w) 

K,  =  T/pD4n2 


V 


0 


Advancing  velocity  of  the  propeller. 


H  i 


D  :  Diameter  of  the  propeller, 

n  ;  Propeller  rps. 

V  Velocity  of  the  ship. 

;  Coefficient  of  the  wake. 

:  Thrust  generated  by  the  propeller, 

p  Density  of  the  sea  water. 

The  relation  between  J  and  Kt  is  shown  in  Figure  A-2.  This  is  the  result  of  the  pro¬ 
peller  test,  so  the  actual  thrust  is  T(l-t)  where  t  is  the  coefficient  of  thrust  reduction. 


Figure  A-1.  Coordinates  for  equations. 


w  ;  W*ke  fKlor  I  :  Unit  reduction  fuctor 

.  :  Density  of  sea  water  ft .  ;  Density  of  air 

g  :  Cnviiy  acceieraiion  A  ;  Frontal  ptojection  area 

B  :  Side  projection  area 

Table  A-1.  Coefficients. 


Figure  A-2.  Kt  vs.  J. 
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A-^  Forrfi  generated  bv  Ihg  tn4(l£r 

The  force  generated  by  the  rudder  is  represented  by  following  equations 

Fn  =  0.5pARUR2sinajj*fa(A) 
fn(A)  =  6.13A/(A+2.25) 

(UR/Up)2  =  0.467(Kt/j2)  +  2.667 
Up  =  (l-w)u 

Normal  force  on  the  rudder. 

Inflow  velocity  to  the  rudder. 

Inflow  velocity  to  the  propeller. 

Angle  of  attack  of  the  rudder. 

Aspect  ratio  of  the  rudder. 

Velocity  of  the  ship. 

A-4  Effect  of  the  wind(9) 

The  force  by  the  wind  is  given  by  the  following  equation  : 

Cr  =  R/(0.5p^Uw^(Acos2(ti  +Bsin2(ti)) 

R  ;  Force  by  the  wind. 

Uw  :  Velocity  of  the  wind. 

;  Density  of  the  air. 

:  Relative  direction  of  the  wind. 

A  :  Frontal  projection  area. 

B  Side  projection  area. 

Relations  Cr  vs.  «,  a  vs.  6  and  aA.  vs.  «.  are  shown  in  Figures  A-4.  A-5 
respectively. 
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Figure  A-3.  Effect  of  the  wind. 
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Figure  A-4.  Cr  vs.  (j). 
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1.  ABSTRACT 

This  paper  describes  the  results  of  a  project  undertaken  by  YARD  LTD  for  MOD  to 
provide  a  demonstrator  of  the  feasibility  of  using  Knowledge  Based  Systems  (KBS)  as  a 
decision  support  aid  within  the  damage  control  area.  The  project  has  been  motivated  by 
the  requirement  for  future  improved  decision  support  to  the  Damage  Control  Officer 
(DCO)  to  counteract  the  effect  of  reduced  manning  levels  and  to  increase  damage  control 
effectiveness. 

Fire  and  smoke  damage  in  a  single  zone  of  a  typical  frigate  was  selected  as  a 
representative  application.  The  zone  contains  a  Machinery  Space,  Ship  Control  Centre, 
Magazines  and  various  other  compartments  and  is  sufficiently  large  to  consider  the  effects 
of  fire,  smoke  and  heat  spread  and  to  provide  scope  for  multiple  damage  incidents.  The 
damage  sensor  fit  in  each  compartment  can  be  varied. 

The  design  and  implementation  of  the  demonstrator  EXpert  Damage  Assessor 
(XDA)  is  based  on  the  strategy  of  modelling  the  tasks  the  DCO  is  faced  with  and  how  he 
solves  them.  The  knowledge  base  contains  a  detailed  representation  of  the  information 
with  which  the  DCO  reasons,  including  knowledge  about  compartments,  physical  links 
and  connections  between  compartments,  the  damaM  sensors  and  other  relevant  ship 
systems,  the  status  of  damage  and  consequences  of  damage  responses. 

The  damage  scenario  is  generated  on  a  remote  data  entry  facility  (RDEF)  using 
graphical  representations  of  the  ship  layout  and  damage  surveillance  sensors.  The  RDEF  is 
networked  to  XDA  and  allows  a  predefined  scenario  to  be  generated  and  input  to  XDA. 
The  scenario  can  be  changed  during  a  run  in  response  to  ac^ice  on  actions  provided  by 


The  paper  describes  the  main  features  of  XDA  and  demonstrates  how  XDA 
responds  to  a  typical  damage  scenario. 

The  principal  conclusion  is  that  KBS  can  assist  in  assessing  a  damage  incident  using 
remote  sensing  or  damage  data,  and  advising  on  priorities  for  action  and  providing  the 
operator  with  information  on  the  ship  systems  etc.  relevant  to  the  context  of  the  damage 
incident. 
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2.  INTRODUCTION 


In  this  paper  we  describe  some  of  the  results  of  a  study  to  establish  the  feasibility 
and  effectiveness  of  using  knowledge  based  systems  within  damage  control  on  a  fighting 
ship.  The  principal  topic  is  the  description  of  a  demonstration  system  which  has  been  used 
to  assess  tne  feasibility  and  effectiveness  of  KBS  in  Damage  Surveillance  and  Control 
(DSAC). 

The  paper  is  structured  as  follows.  In  Section  3,  we  discuss  why  knowledge  based 
technology  can  be  expected  to  impact  on  damage  control.  We  give  some  general  reasons 
and  include  a  brief  description  of  the  results  of  other  studies  undertaken  within  the  UK 
which  gave  further  evidence  of  the  expected  benefits.  We  also  indicate  how  this  earlier 
work  relates  to  the  present  study  and  we  note  how  some  of  these  strands  have  developed. 
In  Section  4  the  selection  of  the  application  is  discussed  and  its  scope  and  user  interface 
requirements  are  briefly  described.  Section  5  goes  over  the  features  of  XDA  ;  its  design, 
some  details  of  the  models  and  knowledge  base  used  and  the  user  interface.  This  is 
followed  in  Section  6  by  a  mainly  pictorial  section  which  takes  the  reader  through  a 
damage  incident  and  its  assessment  by  XDA.  The  final  section  gives  our  conclusion  for  this 
work.  An  appendix  is  included  which  gives  an  outline  of  the  stages  of  the  development 
lifecycle  for  KBS  used  within  YARD  in  order  to  place  the  present  study  within  the 
experimental  stage  of  that  lifecycle.  A  list  of  abbreviations  is  given  in  Section  1 1 


3.  THE  POTENTIAL  OF  KBS  WITHIN  DAMAGE  CONTROL 


The  potential  value  of  KBS  technology  within  Damage  Control  arises  from  its  ability 
to  collect  and  process  large  amounts  of  information  using  knowledge  gained  from  experts 
in  a  stress-free  environment. 


A  subject  as  complex  as  DSAC  inevitably  has  many  difficulties  associated  with  the 
successful  implementation  of  damage  control  procedures.  However,  given  sufficient 
time, full  information  and  adequate  resources,  an  MEO  could  effectively  select  the  most 
effective  procedures  for  the  problems  with  which  the  ship  is  faced.  Proolems  arise  when 
these  actions  are  required  with  deficient  information  and  limited  resources  under 
pressure  of  time  and  other  environmental  pressures. 

These  difficulties  manifest  themselves  in:- 

•  problems  of  communication,  including  the  reliance  on  voice 
communication  from  remote  sources  and  within  the  SCC,  and  the  reliance 
on  personnel  to  convey  information. 

•  problems  of  assessment,  including  the  difficulty  of  assessing  the  actual 
damage  state,  the  threat  to  compartments  from  the  fire,  the  priority  for 
action  and  the  full  consequences  of  an  action. 

•  problems  of  vulnerability,  including  the  possibility  of  an  untenable  state  of 
the  SCC  and  the  loss  of  DSAC  personnel. 
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The  solutions  to  these  difficulties  are  not  straightforward,  but  they  do  all  relate  to 
the  collection,  storage,  processing  and  distribution  of  information  and  expertise.  In  this 
context,  there  is  scope  for  much  more  extensive  use  of  advanced  information  technology, 
in  particular  KB  technology  and  User  Interface  technology,  to  assist  with  some  of  these 
functions.  The  work  reported  in  this  paper  has  investigated  the  feasibility  and  benefits  of 
KBS  as  a  decision  aid. 

3.1  Previous  work  relevant  to  KBS  in  DSAC 


At  the  start  of  the  project  there  had  been  some  previous  work  as  to  how  KBS 
might  be  exploited  in  the  area  of  damage  control. 

(a)  Feasibility  Studies.  MOD(P£)  had  previously  commissioned  feasibility  studies  on 
the  Application  of  KBS  within  the  Ship  Control  Centre  (SCO.  The  recommendations 
from  all  of  these  is  that  there  are  substantial  benefits  to  be  gained  from  the  use  of  such 
technology  in  a  variety  of  roles  in  the  SCC. 

The  possible  application  areas  of  KBS  in  the  SCC  are  addressed  in  reference  1 . 
Focussing  on  DSAC  the  principal  benefits  identified  include;- 

•  an  improvement  in  the  speed  and  accuracy  of  damage  reporting 

•  a  reduction  in  the  information  processing  demands  on  SCC  personnel 

•  assistance  in  the  trend  towards  integration  of  MCAS  and  DSAC  systems 

•  a  higher  degree  of  damage  control  readiness 

•  an  improved  training  facility 

•  more  efficient  control  of  machinery  and  resources 

•  facilitation  of  the  proposed  reduction  in  manning  levels. 

A  further  report  on  Systems  and  Methods  for  Future  DSAC  (Reference  2) 
concludes  that  by  the  application  of  modern  technology  it  is  possible  and  practical  to 
improve  DSAC  facilities  beyond  those  currently  in  service.  Particular  reference  is  made  to 
the  advantages  of  introducing  KBS  to  DSAC.  Additionally,  the  authors  point  towards  the 
use  of  advanced  MMI  to  fully  exploit  the  benefits  of  KBS. 

The  report  also  highlights  the  often  ignored  need  to  integrate  at  an  early  stage  the 
requirements  of  the  user  in  the  design  of  the  KBS.  The  user  interface  should  not  be 
considered  after  design  of  the  KBS. 

(b)  An  Expert  System  for  Damage  Control.  A  thesis  on  An  Expert  System  for 
Damage  Controf  (reference  3)  provides  a  review  of  expert  systems  and  damage  control 
and  of  software  and  hardware  for  expert  systems,  a  description  of  the  implementation  of  a 
prototype  damage  control  expert  system  and  an  estimate  of  the  size,  in  terms  of  the 
number  of  rules,  of  a  full  damage  control  expert  system. 

The  principal  conclusions  of  the  report  are  that  the  use  of  expert  systems  to 
produce  a  damage  control  advisor  is  feasible  and  desirable  and  that  the  full  system  should 
^  implemented  as  a  forward  chaining  rule  based  system.  This  demonstrator  is  built  as  a 
forward  chaining  system  for  two  principal  reasons  :  namely,  it  allows  for  the  iterative,  on¬ 
site  development  of  the  rule  base  by  the  expert  and  it  is  an  appropriate  reflection  of  the 
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problem  faced  in  providing  damage  control  advice.  More  specifically  the  author  states 
that: 


"since  the  damage  control  advisor  would  be  expected  to  follow  the  route  of 
the  damage  control  incident,  which  could  not  necessarily  be  forecast,  the 
forward  chaining  strategy  of  moving  from  the  data  toward  the  overall  goal  is 
most  appropriate."  (p.9T 

In  our  work  we  chose  to  tackle  the  problem  of  representing  reasoning  strategies 
and  knowledge  representation  formalisms  used  in  a  complex  problem  such  as  damage 
control  by  using  a  suitable  software  architecture.  This  arcnitecture  is  known  as  a 
blackboard  arcnitecture  (reference  4)  and  is  recognised  as  being  a  basis  for  dealing  with 
such  problems  in  real  time  systems  (see  Section  5.1). 

(c)  The  Statejpoard  as  Input.  Many  authors  stress  the  importance  of  maintaining  the 
primacy  of  the  stateboard  as  a  display  facility.  It  provides  a  central  source  of  information  on 
the  status  of  the  ship  which  in  this  form  can  be  relocated  should  the  need  arise.  Dorey's 
work  (reference  5)  demonstrates  how  the  the  use  of  the  stateboard  as  an  input  device 
could  form  part  of  a  damage  control  information  system  which  would  help  overcome 
some  of  the  problems  in  current  damage  control  practice.  Indeed  he  suggests  that  further 
benefits  could  be  gained  if  it  was  extended  to  provide  input  to  an  expert  system  for 
damage  control. 

Dorey  used  a  digitised  stateboard  in  order  to  provide  the  inputs  to  a  damage 
control  position  (HQ1 )  with  the  two  main  repair  posts.  In  this  way  all  positions  were  fed  the 
same  updated  information  while  removing  the  need  for  verbal  communications.  Dorey's 
work  indicated  that  this  technique  dealt  very  efficiently  with  fixed  format  data  such  as 
stateboard  information  or  equipment  status  reports.  A  small  scale  version  of  a  digitised 
system,  linking  the  ANBCDO  in  HQl  with  the  command  in  the  Operations  Room  is 
currently  being  evaluated  by  the  Royal  Navy  at  sea. 

(d)  Damage  Control  Retrieval  System.  Knowledge  engineering  requires 
considerable  effort  collecting  and  organising  knowledge.  This  knowledge  includes 
information  about  the  ship,  ship's  systems,  and  the  expertise  used  in  detecting  and 
controlling  damage.  Much  of  this  knowledge  is  factual  and  encyclopaedic. 

Work  on  this  area  is  being  done  for  the  computer  assisted  damage  control  data 
retrieval  system  This  system  is  required  to  provide  fast  retrieval  and  display  of  damage 
control  information.  More  specifically,  it  provides  a  database  about  the  ship  and  its 
compartments. 

The  shipwide  data  contains:- 

•  Watch  and  Quarter  Bills 

•  Shipwide  disposition  of  fixed  and  portable  NBCD  equipment 

•  Ship  stabili^  information 

•  X,Y,Z,A  ana  M  Closure  details 

•  Jettison  Bill 

•  Gas  Drench  guidance 

•  El^trical  Storage  Breaker  Book 

•  Siting  of  gas-bottle  stowages. 
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The  data  for  compartments  includes.- 

water,  etc.) 

•  Electrical  Dependencies 

:  ZSS  apng  toundary  cooling  of  5ie  compadmem 

•  Ventilation  isolation 

•  Smoke  Clearance  and  control 

•  Flood  Removal 

1  Layoul^detlils  and  neighbouring  compartments. 

The  systems  also  provides  facilities  for  incident  logging,  including;- 

•  the  type  of  incident 

•  time  of  initial  report 

•  time  of  containment 

•  time  of  completion 

•  location  mark. 

^  oJiasatf.iS's'js 

LncyXp^dl  S  OSAC  knowledge  from  the  Demonstrator. 

4  SELECTION  OF  THE  APPLICATION. 

Ventilation  systems.  Smoke  curtains  etc. 

4  1  see  PSAC  Personnel 

It  was  decided  that  the  KBS  demonstrator  should  be  a 
DCO.  Kve  some  context  to  this  decision  a  brief  description  of  the  SCC  DSAC 

personnel  IS  now  included. 


Overall  responsibility  for  the  ship  lies  with  command.  DSAC  personnel  in  the  SCC 
co-ordinate  all  damage  control  activities  and  provide  command  with  a  current  picture  of 
the  status  of  the  ship  and  ship's  systems.  The  principal  DSAC  personnel  are:- 

•  The  Action  NBCD  Officer  (ANBCDO),  usually  the  MEO, 

•  Damage  Control  Officer  (DCO)  usually  a  non-engineering  branch  junior 
officer, 

•  Electrical  Damage  Officer,  usually  a  senior  Chief  Petty  Officer, 

•  Propulsion/  Auxiliary  Systems  Officer,  usually  a  senior  Chief  Petty  Officer, 

•  An  NBC  Protection  Officer's  Assistant,  usually  a  senior  Chief  Petty  Officer, 

•  2  Incident  Board  Operators. 

(t  is  the  MEO's  responsibility  to  assess  the  implications  of  damage  to  the  ship,  relay 
and  receive  information  to  and  from  command  and  decide  on  priorities  for  damage 
control  action. 

Response  to  damage  to  the  ship  follows  the  general  sequence  of:- 

•  Detection  -  the  initial  notification  that  damage  has  occurred 

•  Immediate  Action  -  in  most  cases  involving  the  implementation  of  pre¬ 
planned  procedures 

•  Assessment  -  collection  of  information  to  build  up  an  overall  picture 

•  Containment  -  to  limit  the  spread  of  damage 

•  Priorities  -  considering  the  overall  demands,  decide  on  the  best  allocation 
of  resources 

•  Restoration  -  restore  the  ship  to  maximum  availability. 

The  wide  variety  in  time,  location  and  type  of  events  that  can  occur,  means  that 
such  a  formulation  of  the  problem  is  inevitably  a  generalisation.  Any  of  these  tasks  can 
involve  a  series  of  complex  steps. 

The  demonstrator  currently  provides  support  to  each  of  these  activities  to  a  greater  or  less 
extent. 

4.2  Scope  of  XDA 

It  was  not  the  intention  to  provide  a  full  scale  demonstrator.  Rather,  in  keeping 
with  approach  suited  to  this  early  experimental  stage  in  a  KBS  lifecycle  (see  Appendix), 
the  requirements  of  the  demonstrator  were  constrained  as  follows. 

It  was  assumed  that  none  of  the  bulkheads  are  breached  during  the  incident. 
Modelling  breach  of  bulkheads  would  require  dynamic  modification  of  the  model  of  the 
ship's  layout. 

Detection  and  containment  of  fire  and  smoke  would  be  the  sole  aim  of  the 
demonstrator.  There  would  be  no  requirement  to  consider  MCAS  status,  stability  or  the 
possibility  of  flooding  in  deriving  fire-fighting  actions. 

There  would  be  no  requirement  to  implement  a  realistic  model  of  fire  and  smoke 
spread  within  the  demonstrator.  Although  such  models  exist  they  are  currently 
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rudimentary  and  lack  the  necessary  accuracy.  Information  gained  from  sensors  therefore 
provide  greater  accuracy  at  the  present  time  although  fire  models  may  in  future  bridge 
the  gap  after  sensors  had  suffered  damage  and  could  no  longer  be  relied  on 

The  required  sensor  fit  for  efficient  use  of  KBS  in  DSAC  was  as  much  of  interest  as 
the  use  of  KBS  itself.  Therefore  it  would  be  acceptable  to  assume  a  sensor  fit  which  is 
more  extensive  than  the  current  norm.  In  addition  to  the  number  of  sensors  employed, 
some  latitude  was  taken  in  the  types  of  sensor  used.  These  were  not  those  which  are 
currently  fitted,  but  are  restrictea  to  types  which  are  available  or  will  shortly  become 
available.  The  level  of  sensor  fit  can  be  varied 

It  was  assumed  that  no  damage  would  be  sustained  to  the  sensors  themselves.  The 
problem  of  sensor  validation  has  been  addressed  in  other  studies  undertaken  by  YARD 
(reference  6). 

Only  fire-fighting  equipment  within  the  current  fit  could  be  assumed.  No 
automatic  initiation  of  fire-fignting  would  be  necessary.  The  key  requirement  is  to  offer 
advice. 

To  summarise,  the  program  should  be  able  to;- 

•  monitor  and  collect  remote  sensor  information 

•  reliably  interpret  this  information  to  give  an  overall  assessment  of  the 
damage  situation 

•  provide  advice  on  appropriate  actions. 

4,3  The  User  Interface 

It  was  recognised  that  the  design  of  the  user-system  interface  is  a  critical  factor  in 
demonstrating  the  feasibility  of  KBS  in  DSAC.  However  good  the  rule  base  and 
inferencing  mechanisms,  the  effectiveness  usability  and  user  acceptability  of  the  system 
would  be  to  a  large  extent  dependent  on  the  effectiveness  of  user-system  interaction.  The 
study  has  not  fully  analysed  these  problems  but  does  identify  user  interface  aspects 
needing  attention. 

5.  WHAT  XDA  CAN  DO 

.  .  ,  In  section  the  principal  features  of  XDA  are  described,  in  some  cases  including 
a  brief  discussion  of  issues  raisra  in  selecting  or  implementing  the  features. 

In  keeping  with  the  experimental  nature  of  the  demonstrator,  the  implementation 
has  used  much  of  the  functionality  of  the  Al  development  environment.  This  has  meant 
that  a  complex  software  program  has  been  rapidly  developed  using  the  facilities  offered  by 
the  development  environment.  A  next  stage  would  involve  developing  a  full  scale  system, 
probably  re-engineered  on  a  platform  more  suited  for  delivery 
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The  main  features  are 

•  principle  of  the  underlying  design 

•  model  of  the  ship  structure 

•  model  of  indiviaual  compartments 

•  relationships  between  compartments 

•  model  of  sensor  values 

•  ship  systems 

•  simulation  of  sensor  values  and  the  ability  to  alter  sensor  fit 

•  fire  and  repair  party  reports 

•  continuous  data  input 

•  the  rule  base 

•  the  validation  of  the  rule  bases 

•  the  fire  model  and  reasoning  about  single  and  multiple  incidents 

•  the  user  interface 

•  the  integration  of  DCDR. 

A  description  of  the  response  of  XDA  to  a  multiple  fire  incident  is  given  in  the  next 
section.  These  two  sections  talten  together  should  provide  the  reader  with  a  clear 
understanding  of  XDA.  Detailed  functional  description  is  not  given. 

5.1  Principles  of  the  underlying  design 

In  attempting  to  solve  any  complex  problem  experts  use  a  range  of  problem  solving 
techniques,  in  addition  to  their  domain  knowledge.  Different  procedures  are  most 
appropriate  in  different  situations.  For  example,  the  methods  used  by  the  expert  in  the 
initial  interpretation  of  active  sensors  are  different  from  those  he  adopts  to  plan  fire 
fighting  actions. 

The  design  and  implementation  of  XDA  is  based  on  a  model  of  the  tasks  the  expert 
is  faced  with  in  damage  control  and  the  strat^ies  he  employs  to  solve  them.  In  addition 
to  providing  a  principle  for  design  activity,  this  will  lead  to  improved  performance  and  be 
more  acceptable  to  users. 

Based  on  our  previous  experience  of  KBS  in  real  time  systems,  we  decided  to  use  a 
blackboard  architecture  with  separate  processes  being  used  to  implement  components  of 
the  architecture.  In  a  blackboard  architecture  a  set  of  sub-domain  experts  (knowledge 
sources)  operate  on  a  common  data  area  (the  blackboard),  in  this  case  the  models  of  the 
ship  and  of  fire,  revising  and  updating  the  blackboard  as  they  see  fit.  Such  an  architecture 
is  recognised  as  being  suitable  for  continuous,  real  time  data.  Furthermore  the  inherent 
modularity  in  the  design,  with  separate  knowledge  sources,  accommodates  (a)  a 
structured  approach  to  knowledge  acquisition,  (b)  the  addition  of  new  functionality  in  any 
future  developments  and  (c)  the  future  maintenance  of  the  knowledge  base. 

5.2  The  Model  of  the  Ship  and  Ship's  Systems 

Constructing  a  demonstrator  showing  the  feasibility  of  KBS  techniques  for  damage 
control  on  ships  requires  more  than  knowledge  about  how  to  interpret  damage  situations 
and  how  to  prescribe  appropriate  fire  fighting  actions.  To  demonstrate  the  full  potential  of 
KBS  it  is  essential  that  a  sophisticated  and  flexible  model  of  the  ship  is  a  part  of  the 
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demonstrator.  Such  information  is  a  central  part  of  the  knowledge  possessed  by,  or 
available  to,  a  DCO  when  dealing  with  a  damage  situation. 

The  knowledge  base  in  this  demonstrator  contains  a  powerful  representation  of 
the  appropriate  features  of  the  ship,  including:- 

•  knowledge  about  the  compartment 

•  the  relationships  between  the  compartments 

•  the  damage  status  of  the  compartments 

•  the  sensors  and  the  relevant  ship's  systems. 

This  model  is  currently  equipped  to  cope  with  a  considerable  expansion  in  the 
scope  of  the  possible  damage  scenarios.  It  is  also  straightforward  to  incorporate  other 
features  of  the  ship,  relating  either  to  the  ship's  systems  or  the  process  of  reasoning  about 
the  damage  situation.  Additionally,  the  specific  representation  principles  used  in  its 
construction  are  easily  generalisable  for  use  in  other  ships. 

5.3  Model  of  Ship  Compartments 

The  zone  of  the  ship  represented  in  the  knowledge  base  is  described  in  terms  of 
ship  compartments.  All  of  the  compartments  are  represented  as  being  members  of  the 
class  "Compartments".  They  are  in  turn  subdivided  into  members  of  Compartments  on  a 
particular  deck.  The  use  of  structured  inheritance  allows  the  assignment  of  properties 
relevant  to  all  compartments,  by  assigning  the  property  to  the  class.  This  mates  it 
economical  to  input  compartment  information,  and  straightforward  to  reason  about  all 
compartments.  The  information  in  the  slots  are  statements  about  the  compartment  e.g. 
the  criticality  of  the  compartment  or  the  extent  of  heat  threat  to  which  the  compartment 
is  subject,  or  relationships  with  other  units  such  as  the  adjacent  compartments  or  the 
compartments'  smoke  sensor. 

These  slots  contain  information  which  is  fixed  under  all  circumstances  such  as 

•  the  compartments  adjacent  to  this  one 

•  the  ventilation  systems  in  the  compartment 

•  the  type  of  the  compartment 

•  the  sensors  in  the  compartment. 


and  information  which  may  change  a  number  of  times  in  the  course  of  a  damage  scenario 
such  as 


•  the  probability  of  a  fire  in  the  compartment 

•  the  status  of  the  ventilation  systems  in  the  compartment 

•  the  assessed  priority  for  fire  fighting  action  for  the  compartment. 

Such  data  is  used  for  reasoning  about  the  state  of  the  ship  and  the  requirements  and 
progress  of  damage  control. 

5.4  Relationships  between  Compartments 

An  important  feature  of  the  model  of  the  ship  is  the  physical  relationships  between 
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the  compartments.  A  damage  adjacent  above  antTbllow  all  of  the 

needs  to  be  aware  of  which  rnmoartment  the  system  must  know 

Ve  by^he  «,e  and  how  to  g«  to  .he  con.pa..men.. 

TO  .hi.  end  a  compar.men,  has  do»  Wng  ysKm'whTn 

PnSlSoXKoSiilrdaa  dicnbing  .he  boondaries  of  compadmen.s 
Model  of  Sensors 

practician  c^’u^em biSd Ihljs" Thise 
KBS  cover;- 

•  smoke 

•  ambient  heat 

•  flame 

.  boundary  temperature 

•  door  status 

•  ventilation  system  status. 

values  "no  smoke",  "light  smoke",  "medium  smoke'  and  heavy  smoke  . 

A  oualitative  representation  such  as  this  reflects  human  expert  thinWng  and 
knowledge  reSrentation  in  KBS,  and  should  not  be  seen  as  a  poor  subst.  u«  for  a  more 
precise  n^umerical  representation.  It  is  a  very  powerful  and  appropriate  method. 

The  sensors  for  door  status  indicate  whether  the  door  is  open  or  closed.  The 
ventilation  system  sensors  show  whether  the  particular  ventilation  system  is  running  or 
stopped. 

s.ft  Ship's  Systems 

The  model  of  the  ship  contains  a  limited  number  of  the  fire  hghting  facilities 
normally  available  on  the  ship.  A  relevant  subset  of  the  HPSW  and  ^  ® 

Included  This  allows  the  possibility  of  smoke  spread  and  clearance  by  the  venti 
system,  and  also  for  the  selection  of  the  most  appropriate  fixed  fire-fighting  system  t 

tackle  the  problem. 

The  ventilation  system  in  this  zone  includes:- 

•  Machinery  space  supply  and  exhaust 

•  Air  treatment  units 

•  Air  filtration  units 

•  Supply  fans 

•  Exhaust  fans. 
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The  HPSW  system  consists  of:- 

•  Machinery  space  sprayers 

•  Magazine  sprayers. 

5.7  Simulation  of  sensor  values  and  the  ability  to  alter  sensor  fit 

XDA  has  the  facility  to  alter  the  sensor  fit  prior  to  running  scenarios,  in  order  to 
assess  the  performance  of  the  system  with  different  levels  of  sensor  information.  This 
setting  of  sensor  fit  is  controlled  from  the  Remote  Data  Entry  Facility  (RDEF). 

The  RDEF  is  a  separate  system  on  which  a  user  can  set  the  values  of  sensor  data  in 
each  compartment  in  accordance  with  a  pre-planned  scenario  for  a  damage  incident. 
The  user  sets  the  values  using  an  interactive  display  of  compartments  and  sensors  and 
sends  the  data  to  XDA.  It  is  essential  that  the  user  maintains  a  consistent  model  of  the  fire. 
This  facility  implements  a  simple  simulation  of  the  sensor  system  which  communicates 
with  XDA. 

5.8  Fire  and  Repair  Party  Reports 

XDA  uses  both  sensor  information  and  FRP  Reports  as  the  basis  for  damage 
assessment.  XDA  offers  the  facility  to  input  simulated  personnel  reports  about  the  fire  and 
smoke  damage  status  of  compartments.  This  is  done  by  pointing  at  the  compartment 
icon  in  the  ship  display  and  selecting  the  required  menu  item. 

All  data,  sensor  and  personnel  reports,  contribute  to  the  damage  assessment 
process.  Entry  of  either  type  of  data  is  sufficient  to  initiate  assessment.  In  XDA,  much  as  In 
the  real  situation,  FRP  Reports  take  priority  over  sensor  data. 

5.9  The  Rule  Bases 


We  give  here  a  brief  summary  of  the  rule  bases  used  in  XDA  and  their  inputs  and 
objectives.  XDA  contains  the  following  knowledge  sources,  represented  either  as  rule 
classes  or  LISP  procedures:- 

Fire-damage-status-rule  use  fire  sensor  data  and  FRP  fire  reports  about  a 
compartment  to  conclude  the  fire-damage-status  of  the  compartment. 

Smoke-damage-status-rule  use  smoke  sensor  data  and  FRP  smoke  reports  about  a 
compartment  to  conclude  the  smoke-damage-status  of  the  compartment. 

Fire-model-rules  are  used  to  maintain  the  units  representing  the  fire.  They  use  the 
damage-status  and  physical  relations  of  compartments. 

Smoke-threat-rules  use  the  fire-damage-status  and  the  smoke-damage-status, 
physical  relations  and  ventilation  systems  to  determine  the  smoke-threat  to  a 
compartment. 

Heat-threat-rules  use  the  fire-damage-status  and  the  smoke-damage-status  and 


3.212 


physical-relations  to  determine  the  heat-threat  to  a  compartment. 

Compartment-concern-rules  use  the  fire-damage-status  and  the  smoke-damage- 
status,  heat-threat,  smoke-threat  and  compartment-type  of  a  compartment  to  conclude 
the  concern-level  associated  with  a  compartment. 

Priority-rules  use  concern-level  and  compartment-value  to  conclude  the  priority- 
for-action  on  a  compartment. 

Boundary-cooling-rules  use  the  damage-status,  heat-threat,  accessibility  of 
compartments  to  advise  on  boundary  cooling  of  a  compartment. 

Ventilation-system-restart-rules  use  the  assessed-fire-model  to  determine  whether 
the  ventilation  system  can  be  restarted. 

Fixed-fire-fighting-system-rules  use  the  assessed-fire-model  and  the  ship-model  to 
advise  on  the  use  of  fixed  fire  fighting  systems. 

5.10  Validation  of  Rule  Base 

A  rigorous  approach  to  the  development  and  testing  of  the  rule  bases  was  used. 
The  rule  bases  for  XDA  were  documented  in  a  structure  and  format  that  permitted  the 
MOD  to  assess  the  rules  without  use  of  the  demonstrator.  Changes  to  the  rule  bases  and 
the  addition  of  further  rule  bases  are  documented  in  the  same  manner.  This  document 
was  maintained  throughout  the  project  as  a  public  record  of  the  current  state  of  the  rule 
base.  It  provides  a  degree  of  visibility  and  clarity,  together  with  a  basi  f  r  verification  not 
easily  achieved  with  the  coded  representation. 

The  generation  of  the  paper  version  of  the  rule  base  was  assisted  by  the  use  of  an 
intermediate  form  of  representation  where  the  rules  were  summarised  in  tabular  form. 
This  method  began  by  identifying  the  the  objectives  of  the  rule  base.  These  are  matched 
in  a  matrix  with  the  possible  values  of  the  range  of  input  variables.  This  makes  it  relatively 
straightforward  to  specify  the  combinations  of  input  variables  that  combine  as  a  rule  to 
give  each  conclusion.  Once  complete,  each  row  of  the  matrix  is  in  effect  a  single  rule, 
with  translation  to  the  'English'  paper  representation  of  the  rules  a  straightforward  task. 

5.1 1  The  fire  model  and  reasoning  about  incidents 

In  handling  multiple  damage  incidents,  the  evaluation  of  damage  threat  for  one 
incident  must  take  account  of  others.  XDA  takes  account  of  the  context  of  a  damage 
incident  in  Determining  the  threat  posed  by  the  incident  and  in  deciding  the  level  of 
action  required. 

This  is  achieved  by  the  use  of  an  explicit  model  of  the  fire(s)  held  by  XDA.  The  fire- 
model-maintainer-process  and  the  fire-model-assessor  processes  are  dedicated  to 
updating  units  representing  the  current  fire  damage  believed  to  be  affecting  the  ship. 

This  representation  of  the  Tire  includes  properties  such  as  the  affected-compartments, 
fire-incident-boundary,  smoke-threatened-compartments  and  the  heat-threatened- 
compartments.  By  combining  this  with  various  compartment  properties  relating  to  fire 
damage,  such  as  fire-damage-status,  smoke-damage-status,  concern-level  and  source-of- 
concern,  XDA  can  successfully  discriminate  between  the  affects  of  different  incidents  and 
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prioritise  the  need  for  action  accordingly. 
■S.12  The  user  interface 


XDA  has  been  provided  with  a  user  interface  equivalent  to  that  needed  by  an 
operator. 

fa)  User  control.  The  user  has  a  high  degree  of  control  over  the  display  of 
information  in  XDA.  The  displays  of  the  fire  representation  or  the  advice  will  not  change 
unless  the  user  initiates  the  cnange.  The  user  is  primed  when  the  screen  display  is  not 
current. 

fh)  .Shin  Displays.  There  are  two  displays  of  information  on  ship  status,  the  Ship 
Layout  Window  and  the  Ship  Status  Panel.  The  contpartment  icons  in  the  Ship  Layout 
Window  can  be  pointed  at  to  select  menu  items  for  DCDR  access  and  FRP  report  inputs. 
The  Compartment  Status  Panels  in  the  Ship  Status  Window  include  information  on  the 
sensor  values  and  on  the  FRP  Fire  and  Smoke  reports. 

(c)  Fire  Representation  and  Advice.  An  extensive  display  of  XDA’s  current  view  of 
the  fire(s)  is  displayed  upon  request  in  the  Fire  Fighting  Advice  Window.  The  operator  can 
interact  with  this  display  at  the  compartment  and  the  tire  level,  allowing  access  to  advice 
on  boundary  cooling,  smoke  and  heat  threat,  the  use  of  fixed  fire  fighting  systems  and  the 
DCDR  emulation.  All  fire  fighting  advice  is  displayed  in  the  lower  half  of  the  Fire  Fighting 
Advice  Window. 

(d)  DCDR  A  DCDR  emulation  is  provided  for  a  limited  set  of  compartments.  This  is 
accessible  from  the  compartment  icons  in  the  Ship  Layout  Window  and  the  fire 
representation.  It  has  a  similar  layout  to  the  DCDR,  with  a  central  display  and  menu 
buttons  down  the  side  allowing  access  to  specific  information.  Menu  items  are  selected 
by  mouse. 


5.13  The  integration  with  the  DCDR 

The  focus  of  attention  in  XDA  is  less  about  providing  advice  about  fighting  fires  and 
more  about  providing  a  detailed  assessment  of  the  fire  situation.  This  reflects  more 
accurately  the  role  of  the  DCO,  fire  fighting  being  the  responsibility  of  the  team  at  the  fire. 
A  DCDR  emulation  in  XDA  provides  much  of  the  information  supporting  a  DCO's 
activities.  All  DCDR  information  is  accessed  with  the  mouse  through  the  compartment 
icon  in  either  the  Ship  Layout  Window  or  the  Fire  Image  in  the  Fire  Fighting  Advice 
Window.  The  DCDR  information  is  displayed  on  a  alternative  screen  display.  Details  of 
the  DCDR  have  been  given  in  Section  3 
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6.  XDA  RESPONSE  TO  A  DAMAGE  INCIDENT 


In  this  section  we  describe  the  response  of  XDA  to  a  damage  incident  using 
photographs  of  the  XDA  screen  with  an  extended  caption. 

6.1  The  XDA  desktop 

Figure  1  shows  one  deck  of  the  ship  fire  zone  display  in  the  Ship  Layout  Window 
(top  left),  Ship  Status  Window  (top  right).  Software  Engineer's  window  (bottom  right),  Fire 
Fighting  Advice  Window  (bottom  middle)  and  the  Intermediate  Reasoning  Window 
(above  oottom  left). 


Figure  1 .  The  XDA  desktop 
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6.2  RDEF  :  Sensor  value  simulation 

From  RDEF  an  initial  sensor  fit  is  defined  by  setting  smoke,  heat,  fire,  boundary  and 
door  sensors  as  available  or  unavailable.  The  RDEF  is  used  by  the  person  responsible  for 
developing  the  simulation  of  a  fire/smoke  incident  and  is  run  independently  of  XDA.  As 
shown  in  Figure  2,the  data  file  can  be  sent  at  any  time  to  a  buffer  in  XDA  by  selecting  the 
Set  Values  menu.  An  XDA  process  reads  the  buffer. 
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Figure  2.  RDEF  display  and  interaction 
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6.3  First  indications  of  Fire  1 

Data  has  been  sent  from  RDEF.  XDA  correctly  interprets  it  as  a  large  fire  in  the 
recreation  space  with  smoke  spread  outside.  Figure  3  shows  the  sensor  v^ues  displayed  in 
the  compartment  sensor  status  window,  grouped  by  compartment. 


Figure  3.  First  indications  of  FIRE  1 


6.4  The  user  asks  for  advice 


A  second  fire  develops.  There  is  a  fire  in  the  SCC  and  in  the  corridor  outside.  This 
shows  up  (see  Figure  4)  as  a  second  fire  icon  labelled  FIRE  2 


At  this  stage  the  user  can  ask  for  advice  by  selecting  either  the  FIRE  icon  or  the 
compartment  icon.  Advice  covers  zones  fires  and  compartments.  Zone  advice  advises  on 
smoke  control.  Fire  wide  advice  advises  on  boundary  cooling,  use  of  fixed  systems,  display 
of  location,  size  and  source  of  smoke  and  heat  threats.  The  user  has  previously  selected 
advice  on  heat  threats  from  the  pop-up  menu  obtained  by  pointing  at  the  icon  for  FIRE  1 . 
The  heat  threats  are  displayed,  sorted  according  to  the  size  of  the  threat.  The  diagram 
shows  the  selection  of  compartment  advice  which  is  given  via  the  DCDR. 


Figure  4.  Information  by  compartment 
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6.5  DCDR  Access 


The  DCDR  can  be  selected  via  the  ship  layout,  with  the  operator  controlling  the 
selection  options.  Alternatively,  if  the  operator  accesses  the  DCDS  as  ® 

via  the  comoartment  icon  in  the  Fire  Fighting  Advice  Window,  XDA  will  select  the 
appropriate  part  of  the  DCDR  encyclopedia  (Figure  5)  to  display  information  related  to  the 
incident  thus  simplifying  the  operators  task. 

Figure  5  shows  the  SCC  and  the  operator  is  selecting  additional  information  from 
the  selection  buttons. 


Figure  5.  DCDR  layout 
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6.6  Merged  Fires 

FIRE  1  and  FIRE  2  have  merged.  XDA  has  deduced  this  and  shows  in  Figure  6  a 
single,  more  complex  fire  as  FIRE  1.  Figure  6  also  shows  the  operator  inputting  a  FRP 
Report  via  the  Ship  Layout. 


Figure  6.  Merged  fires  and  FRP  Report  input 
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7.  CONCLUSIONS 

7.1  Benefits  of  the  design  of  XDA 


We  estimate  that  about  90-95%  of  XDA  could  be  re-used  in  future  developments 
which  might  include  extension  to  further  zones,  longer  term  damage  incidents,  other 
damage  categories  (flooding,  structural  damage  etc)  or  alternative  uses  than  as  a  decision 
aid  to  the  DCO,  such  as  a  training  aid  or  sensor  set  evaluation. 

The  basis  of  this  estimate  is  that  such  devel^ments  would  involve  revision  of  the 
user  and  hardware  interfaces,  extension  of  the  ship  model  or  the  extension,  amendment 
or  addition  of  knowledge  sources. 

The  modularity  of  the  design  has  been  an  important  principle  which  allows  for  the 
relative  ease  with  which  extensions  to  XDA  could  be  made.  This,  in  tandem  with  the  use 
of  a  blackboard  architecture  allows  the  system  developer  to  add  new  functionality  in  the 
form  of  new  subdomain  expertise  or  knowledge  sources  which  do  not  impact  substantially 
on  the  overall  system.  The  modularity  also  allows  the  decoupling  of  representation  from 
the  functionality  of  the  knowledge  sources,  the  designer  is  free  to  select  the  appropriate 
method  of  representation,  including  algorithmic  or  computational  methods  (e.g.  for 
stability),  for  the  particular  activity.  Furthermore  the  specification  of  the  functionality  of 
each  knowledge  source,  its  implementation  and  its  testing  and  maintenance  is  assisted  by 
the  modularity. 

7.2  The  operation  of  XDA 

The  assessment  of  XDA  has  shown  it  to  be  robust,  although  there  are  a  number  of 
operational  difficulties  which  arise  from  its  prototype  nature  ana  the  features  of  the 
development  environment. 

A  useful  screen  area  has  been  made  available  for  advice  and  assessment,  however, 
the  OTtimum  way  of  displaying  ship  layout  for  a  complete  ship  rather  than  a  single  zone 
needs  careful  consideration  as  will  the  means  of  displaying  sensor  information  from  a  large 
number  of  compartments. 

The  use  of  pull  down  and  pop-up  menus  is  thought  to  be  an  acceptable  means  for 
controlling  the  presentation  but  the  design  will  need  to  ensure  that  the  options  available 
to  a  user  at  any  stage  are  clear  to  even  an  inexperienced  user  in  a  stressful  situation. 

The  rule  base  continues  to  need  enhancement  and  refinement  which  will  come 
through  wider  use  and  further  testing.  However  XDA  is  able  to  recognise  multiple 
incidents,  show  the  boundaries  of  each  incident  and  provide  an  assessment  of  the 
compartments  which  are  threatened  by  fire  and  smoxe  and  recommend  priorities  for 
action  on  incident  affected  compartments, 

7.3  Full  implementation 

XDA  assumes  the  availability  of  a  large  number  of  sensors  throughout  the  ship.  In  a 
true  ship  installation  it  is  likely  that  there  would  be  far  fewer  sensors  f'tted,  primarily  due  to 
the  cost  of  installation  and  maintenance  and  the  limited  extra  information  provided.  Also 
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in  developing  XDA,  a  basic  assumption  has  been  that  the  data  provided  by  sensors  is 
reliable,  whereas  in  a  true  damage  incident  sensors  would  fail  and  either  inaccurate  data 
would  be  provided  or  a  loss  of  data  would  occur.  In  both  these  situations  of  additional 
uncertainty  a  knowledge  based  approach  can  be  used  to  interpret  with  reduced 
information. 

The  validation  of  the  rule  base  would  have  to  be  addressed  prior  to  a  ship 
installation.  It  would  not  be  feasible  to  trace  a  path  through  all  possible  combination  of 
events  to  which  XDA  would  respond.  The  experience  gained  to  date  suggests  that  the  use 
of  a  staged  development  approach  as  outlined  in  the  Appendix  together  with  the 
modularity  of  the  software  architecture  will  provide  an  approach  to  validation. 
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10.  APPENDIX  :  The  Knowledge  Based  System  Lifecycle 

A  KBS  is  implemented  in  software  but  a  conventional  software  lifecycle  is  not 
appropriate  primarily  because  of  the  difficulties  of  specifying  the  knowledge  based 
elements  of  the  system  in  advance  of  design  and  implementation.  Furthermore  there  are 
often  technical  issues  regarding  the  methods  for  representing  knowledge  and  for 
reasoning  with  that  knowledge  which  must  be  resolved  through  prototyping  and 
incremental  development. 
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The  development  of  KBS  software  should  progress  through  the  following  stages. 

a)  A  Preliminary  Study  Stage.  The  potential  application  is  considered  with 
particular  attention  to  its  suitability  for  KBS  techniques. 

b)  An  Experimental  Stage.The  feasibility  of  the  KBS  is  confirmed  and  a 
number  of  decisions  concerning  Knowledge  representation,  reasoning 
mechanisms  and  architecture  are  taken.  A  representative  sub-domain  is 
selected  for  implementation  trials.  The  software  requirements  for  the  next 
stage,  the  Prototvoe  Stage,  should  be  identified. 

c)  The  Prototype  Stage.  This  is  the  first  full  scale  implementation  of  the  KBS 
addressing  the  complete  domain.  The  objective  of  this  phase  is  to  evaluate 
the  KBS  functions  before  developing  an  operational  system.  The  prototype 
will  be  developed  iteratively,  each  cycle  involving  some  modification  of  the 
knowledge  base.  The  user  interfaces  should  be  well  designed.  The 
hardware  interfaces  should  simulate  the  operational  inputs-outputs  so  that 
the  evaluation  can  be  carried  out  using  realistic  data. 

d)  The  Operational  System  Stage.This  consists  of  integrating  the  KBS  in  the 
target  enviro''m''  it.  Software  engineering  methods  should  be  used. 
Maintenance  procedures  must  be  establisned  in  particular  regarding 
modifications  (amendments  to,  additions  to,  or  deletions  from)  the 
knowledge  base. 

Within  each  stage  a  suitable  method  of  work  which  ensures  an  appropriate  set  of 
documentation  should  oe  put  in  place.  YARD  uses  a  development  model  for  knowledge 
engineering  within  each  stage  which  provides  visibility  of  progress  and  ensures  quality  of 
results. 

The  system  described  in  this  paper  is  at  the  experimental  stage,  but  has  been  developed 
using  appropriate  software  engineering  principles. 

12.  ABBREVIATIONS 


Al 

ANBCDO 

DCO 

DCDR 

DSAC 

FRP 

KBS 

MCAS 

MEO 

MOD 

NBCD 

PE 

RDEF 

see 

XDA 


Artificial  Intelligence 
Action  NBeD  Officer 
Damage  eontrol  Officer 
Damage  eontrol  Retrieval  System 
Damage  Surveillance  and  eontrol 
Fire  and  Repair  Party 
Knowledge  Based  System 
Machinery  eontrol  and  Surveillance 
Mechanical  Enjgineering  Officer 
Ministry  of  Defence 

Nuclear,  Biological,  ehemical.  Damage 
Procurement  weeutive 
Remote  Data  Entry  Facility 
Ship  eontrol  eentre 
Expert  Damage  Assessor 
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and  by  Andrew  J.  Mazzeo 
Naval  Sea  Systems  Command 


1 .  ABSTRACT 

This  paper  describes  the  use  of  the  Generic  Controller 
Card  Set  (GCCS)  as  the  nucleus  of  the  Navy  Universal  Digital 
Electronic  Controller  (NUDEC)  in  advanced  systems.  A  NUDEC 
system  provides  both  hardware  and  software  to  implement 
control  algorithms  for  advanced  systems  such  as:  variable 
geometry  inter-cooled  regenerative  (ICR)  gas  turbines, 
electric  plant  load  scheduling,  power  scheduling  for 
propulsion  and  pulsar  weaponry,  or  platform  stabilization  in 
rudder  roll  steering  systems.  Central  control,  distributed 
control,  pre-processing,  post-processing,  and  levels  of 
redundancy  and  fault  tolerance  can  be  achieved  with  Central 
Processing  Units  (CPU's),  Multi-function  Controllers, 
memories,  and  smart  Input/Output  (I/O)  modules.  NUDEC  also 
contains  the  processing  and  memory  capacity  to  implement 
artificially  intelligent  (AI)  expert  systems  for  more  capable 
advance  control  systems.  Comprehensive  module  level  Built- 
in-Test  (BIT)  is  also  supplied  to  diagnose  and  report  module 
or  system  level  failures. 

2 .  INTRODUCTION 

With  the  advent  of  advanced  system  architectures  in 
Naval  combatants  and  support  ships,  control  systems  will  be 
required  to  operate  within  a  high  speed  multi-tasking 
environment.  These  control  systems  will  dictate  the  use  of 
high  speed,  real  time  processors  to  analyze  machinery  sensor 
data,  resolve  intricate  control  algorithms,  and  return  the 
required  control  signals.  Advanced  control  system  modules 
will  be  required  to  operate  as  central  control  elements  for 
processing  common  algorithms  and  performing  supervisory 
duties  as  well  as  distributed  dedicated  processing  elements 
to  effect  fast  data  manipulation  and  fail  safe  checks.  These 
systems  must  also  be  highly  reliable,  cost  effective,  and 
easy  to  maintain.  The  NUDEC  system  is  based  on  a  high  level 
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open  architecture  bus  protocol  (IEEE  1296,  Intel's  Multibus 
II  iPSB)  for  interagent  communications  and  the  implementation 
of  primitive  data  buses  to  perform  dedicated  I/O  control . 
Thus  NUDEC  delivers  the  necessary  centralized  and  distributed 
processing  paths  to  meet  the  requirements  for  managing  these 
advanced  systems.  The  modules  comprising  the  NUDEC  system 
are  format  "E"  Standard  Electronic  Modules  (SEM)  developed  as 
standards  under  the  GCCS  program.  These  modules  incorporate 
all  of  the  reliability  features  of  the  SEM  program,  contain  a 
complete  function  on  a  card,  and  incorporate  module  level  BIT 
circuitry  and  algorithms  to  perform  on-line  diagnostics  and 
fault  logging. 

3 .  BACKGROUND 

There  are  three  major  elements  that  comprise  the  NUDEC 
system:  the  bus  backplane,  the  card  cage/thermal  dissipation 
system,  and  the  GCCS  modules  including  system  unique  signal 
conditioning  (S/C)  modules. 

3 . 1  Bus  backplane 

The  bus  backplane  is  a  twenty  four  slot  multiple  bus 
interconnect  structure  comprised  of  a  single  Intel  parallel 
system  bus  (iPSB),  two  Intel  local  bus  extension  ( iLBX  II) 
buses,  and  a  power  interface/distribution  system.  Four  of 
the  slots  are  reserved  for  SEM  E  power  supplies,  or  as  an 
electrical  interface  for  other  types  of  power  supplies.  The 
power  distribution  system  may  contain  as  many  as  four 
different  source  voltages  and  three  distinct  ground  returns 
within  the  backplane.  Module  slots  are  connected  together  to 
form  a  twenty  module  general  communication  iPSB  protocol 
backplane  on  which  any  of  the  GCCS  modules  can  communicate. 
At  each  end  of  the  iPSB  backplane,  five  slots  are  connected 
to  form  two  iLBX  II  protocol  high  speed  direct  CPU  to  memory 
interfaces.  A  group  of  pins  in  each  slot  is  reserved  for  the 
system  user.  None  of  these  pins  are  connected,  so  all 
connections  between  modules  in  this  region  require  wire 
wrapping.  The  primitive  address/data  buses  (Local/Dual  Port) 
in  a  NUDEC  system  will  reside  in  the  user  defined  area.  This 
bus  allows  general  purpose  communication  initiated  by  a 
Controller  module  to  memories  and/or  I/O  modules.  The  user 
defined  area  will  also  contain  the  S/C  interconnects  to  I/O 
modules,  RS-422  interfaces,  and  cabling  to/from  the  NUDEC. 

3.2  Card  caqe/thermal  dissipation 

The  card  cage/thermal  dissipation  system  holds  the 
backplane,  GCCS,  and  S/C  modules  in  place  and  dissipates  the 
heat  from  the  modules,  format  "E"  modular  power  supplies,  and 
backplane.  Thermal  management  for  the  NUDEC  system  utilizes 
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a  conduction  cooling  scheme  for  heat  dissipation.  The  heat 
generated  by  active  components  on  the  electronic  modules  is 
conducted  through  the  module  frame  to  the  guide  rib  area. 
Wedge  lock  module  retainers  clamp  the  module  guide  rib 
against  the  card  cage  rails,  thereby  providing  a  low  thermal 
resistance  path  between  the  module  guide  ribs  and  the  card 
cage.  Heat  conducted  into  the  card  cage  frame  is  removed  by 
heat  exchangers  located  in  the  rails.  The  heat  exchangers 
transfer  the  heat  to  cooling  air  supplied  through  a  fan/duct 
assembly. 

3 . 3  GCCS  modules 


The  GCCS  consists  of  "building  block"  modules  that  can 
be  configured  to  meet  a  wide  variety  of  controller 
applications.  The  standard  modules  contain  a  complete 
specific  function  and  an  iPSB  protocol  bus  interface. 
Resident  hardware  and  firmware  on  all  modules  assists  in 
system,  module,  and  component  fault  detection  and  isolation. 
The  CPU  module  is  built  around  a  32  bit  processor  and 
coprocessor  core  for  high  level  data  processing  and  floating 
point  math  capability.  Resident  high  speed  pipe-lined  memory 
allows  the  CPU  module  to  operate  efficiently  and  minimizes 
off  card  accesses.  In  dedicated  control  scenarios  the 
Controller  module  is  a  lower  cost  option  to  the  CPU  module. 
The  Controller's  resident  non-volatile  memory  allows  user 
defined  efficient  dedicated  control  tailored  to  the 
application  or  low  level  data  processing  to  augment  a  CPU. 
In  addition  to  Multibus  II  applications,  the  module  can  be 
used  alone  or  with  I/O  modules  in  applications  that  do  not 
require  an  iPSB  interface.  Analog  to  digital  (A/D),  digital 
to  analog  (D/A),  and  discrete  I/O  (DIO)  are  the  present  I/O 
modules.  Application  flexibility  for  the  system  I/O  is 
accomplished  by  varied  operational  mode  capability,  IPSB  bus 
master  interface,  and  primitive  bus  communications  to  the 
Controller  module  through  a  dual  port  memory.  This  memory  is 
accessed  by  the  Controller  module  on  the  Local/Dual  Port  bus 
interface.  The  random  access  memory  (RAM)  and  erasable 
programmable  read  only  memory  (EPROM)  modules  provide 
additional  scratch  pad  or  program  storage.  The  memories 
communicate  with  the  CPU  module  using  the  iLBX  II  bus  and  to 
the  Controller  with  the  Local/Dual  Port  bus.  They  also  act 
as  global  memory  on  the  iPSB  bus  and  can  communicate  with  any 
of  the  processing  or  I/O  modules.  System  unique  S/C  modules 
are  used  to  condition  inputs  from  sensors  and  loads  to  levels 
appropriate  to  the  I/O  modules,  and  to  condition  outputs  from 
the  I/O  modules  to  levels  appropriate  to  the  system.  These 
modules  produce  the  specific  level  shifting,  scaling,  or 
drive  required  for  each  application  that  would  not  be 
appropriate  on  a  general  purpose  module. 
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4. 


CONTROL  HARDWARE  ARCHITECTURE 


The  versatility  of  the  backplane  and  GCCS  module  set 
affords  NUDEC  with  an  efficient  architecture  for  implementing 
high  complexity  controls.  The  multiple  bus  backplane 
supplies  the  interconnect  structure  for  modules,  distributes 
power,  and  interfaces  signals  to/from  the  control  system. 
The  iPSB  bus  allows  high  speed  real  time  communication  for 
centralized  control  to  transpire.  A  centralized  processing 
module  is  able  to  efficiently  receive  sensor  data  and 
transmit  control  data  through  messages  across  the  iPSB  bus 
to/from  other  modules.  The  iPSB  bus  also  promotes  an 
atmosphere  in  which  distributed  processing  can  occur.  Tasks 
can  be  segregated  into  dedicated  fast  ata  manipulation  or 
pre-processing  routines  and  performed  by  additional  processor 
or  I/O  modules.  Pertinent  information  can  then  be  passed  by 
messages  across  the  bus  to  the  central  control  module(s). 
With  the  iLBX  II  buses,  multiple  CPU's  are  able  to  share  fast 
common  memory  and  perform  parallel  processing  on  intricate 
control  algorithms  for  quicker  resolution.  A  NUDEC  system 
will  contain  a  mix  of  GCCS  modules  (processors,  memories,  and 
I/O)  to  perform  the  specific  control  function.  The 
processor  modules  will  handle  system  housekeeping  and 
maintenance  functions  and  supply  control  algorithm  solutions 
from  sensor  data  gathered  by  the  I/O  modules.  Memories  will 
maintain  the  storage  area  for  system  algorithms,  any 
nonresident  processor  specific  routines,  CPU  operating 
systems,  and  system  level  maintenance  routines.  I/O  modules 
are  divided  into  two  types:  GCCS  I/O  modules  and  S/C  modules. 
Machinery  sensor  data  is  transmitted  or  received  by  I/O 
modules  and  passed  from/to  other  GCCS  modules  within  the 
system. 

4 . 1  Processing 

The  two  processing  modules  in  the  NUDEC  system  are  the 
CPU  and  Controller.  They  are  responsible  for  obtaining 
sensor  data  from  I/O  modules,  interpreting  the  data,  solving 
control  algorithms,  and  returning  operational  commands  to  the 
machinery.  In  advanced  control  systems,  communication  with 
other  equipment  or  control  systems  will  be  necessary  for 
integrated  control .  Direct  or  indirect  communication  with 
external  equipment  or  systems  requiring  periodical  or  on 
demand  updates  is  possible  with  the  NUDEC  processing  modules. 
RS-422  interfaces  produce  a  point  to  point  communication 
capability  or  they  can  be  placed  in  a  master/slave 
arrangement.  Advanced  control  systems  will  also  be  required 
to  perform  self  diagnostics  and  operate  with  diverse  recovery 
scenarios.  In  conjunction  with  data  and  control  processing, 
GCCS  processors  may  also  be  tasked  with  the  collection  and 
processing  of  module  fault  data  for  system  use.  This  fault 
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information  is  automatically  generated  in  each  of  the  GCCS 
modules  by  resident  on-line  hardware  and  firmware  and  if 
possible  stored  in  non-volatile  and  iPSB  accessible  memory. 
Bus  and  system  level  diagnostics  can  be  implemented  with  the 
processing  modules  to  aid  in  system  fault  detection  and 
recovery.  The  fault  recovery  could  be  a  simple  safe  shut 
down  of  the  system,  switching  to  a  degraded  mode  of 
operation,  or  a  full  reallocation  of  the  system  resources  to 
maintain  full  operational  capability.  To  perform  effectively 
in  a  centralized  control  system  a  processor  will  be  required 
to  handle  all  system  housekeeping  functions,  solve  all 
control  algorithms,  communicate  with  data  gathering  modules 
and  memories,  and  act  as  the  central  clearing  house  for  all 
control  activity.  The  GCCS  processing  modules  can  handle  any 
system  housekeeping  necessary  to  maintain  a  logical  flow  of 
data  within  the  system.  These  modules  communicate  to  the 
other  agents  (memories  modules  or  I/O  modules)  by  various 
methods  and  on  multiple  bus  paths.  Module  initialization, 
module  configuration,  and  fault  information  is  located  in  and 
accessed  by  the  iPSB  bus  using  the  interconnect  space 
protocol  which  uses  an  eight  bit  single  transfer  of  data 
between  modules.  The  module's  host  processor  is  not  involved 
in  or  interrupted  by  the  module  to  module  interconnect  data 
transfer.  Memory  communications  may  be  conducted  on  the  iPSB 
and  iLBX  II  buses  by  a  CPU  module,  or  on  the  iPSB  and  the 
Local/Dual  Port  buses  by  a  Controller  module.  A  distributed 
control  system  requires  processor  modules  to  perform 
dedicated  processing  and  control  algorithms,  communicate  with 
other  processing  agents,  share  common  memory  space,  and 
control  dedicated  I/O.  A  Controller  module  with  its  resident 
user  memory  is  programmable  for  dedicated  control  and  data 
processing.  Its  implementation  of  the  Local/Dual  Port  bus 
allows  independent  control  of  I/O  resources  and  memory  data 
in  conjunction  with  the  iPSB  global  memory  and  I/O  resources. 
Both  processor  modules  can  communicate  with  each  other  or 
with  I/O  modules  using  unsolicited  message  passing  on  the 
iPSB  bus.  In  the  unsolicited  message  protocol,  a  single  32 
byte  data  packet  is  transferred.  The  CPU's  can  communicate 
using  iPSB  solicited  messages  which  transfers  multiple  32 
byte  data  packets  with  a  single  bus  arbitration. 

4 . 2  Memory 

The  RAM  and  EPROM  modules  provide  mass  data  storage  for 
NUDEC  systems.  EPROM  modules  will  contain  the  non-volatile 
memory  used  by  CPU  modules  for  operating  systems,  system  BIT 
routines,  and  control  programs  and  algorithms.  Any 
additional  non-volatile  data  and  firmware  required  by 
Controller  modules  that  is  not  contained  in  the  resident 
memory  will  reside  on  EPROM  modules  as  well.  The  EPROM 
modules  may  also  be  used  for  storage  of  I/O  module  programs 
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for  download  by  a  Controller  or  CPU  nodule.  All  temporary 
data  storage  in  a  NUDEC  system  will  be  in  RAM  modules  when  on 
board  processor  memory  space  is  insufficient.  Both  memory 
modules  are  dual  access  capable  with  an  iPSB  bus  interface, 
and  another  dual  function  interface  that  can  be  connected  to 
an  iLBX  II  bus  or  the  Controller  module's  primitive 
Local/Dual  Port  bus.  This  multiple  connection  capability 
allows  one  memory  type  to  service  an  entire  system,  thus 
reducing  system  cost  and  complexity.  Up  to  four  memory 
modules  can  be  connected  to  a  single  CPU  module  across  the 
iLBX  II  bus.  To  facilitate  high  speed  multi-processing 
applications  two  CPU  modules  can  be  connected  to  as  many  as 
three  memory  modules  on  an  iLBX  II  bus.  In  addition,  data 
may  be  passed  from  Controller  or  I/O  modules  directly  to  the 
memories  via  the  iPSB  bus,  instead  of  directly  passing  data 
messages  to  a  CPU  module.  This  allows  a  CPU  module  to 
directly  access  data  from  several  sources  across  the  high 
speed  iLBX  II  bus  as  the  data  is  needed.  One  of  each  type  of 
memory  module  can  be  connected  to  a  Controller  module  on  the 
Local/Dual  Port  bus  to  expand  the  module  memory  or  for  use 
instead  of  the  on  board  user  memory.  This  high  speed  multi¬ 
access  capability  enhances  a  NUDEC  system's  ability  to 
control  advanced  systems. 

4.3  I/O 

The  GCCS  I/O  modules  (discrete  I/O,  A/D  converter,  and 
D/A  converter)  are  the  interface  to  the  external  world  from  a 
NUDEC  system.  Each  module  performs  a  single  specific 
function  for  one  or  more  processor  modules,  and  thereby 
supports  the  versatility  and  fault  isolation  capability 
necessary  for  high  complexity  control  systems.  Multiple 
signal  types  can  be  controlled  by  a  single  I/O  module  with 
the  use  of  signal  conditioning  modules.  These  signal 
conditioning  modules  are  used  to  level  shift,  scale,  or 
increase  the  drive  power  for  the  signals  to/from  the  I/O 
modules.  System  fault  detection  and  isolation  is  unaffected 
by  the  addition  of  signal  conditioning  modules,  since  any  I/O 
module  can  control  and  test  all  S/C  modules  to  which  it  is 
attached.  This  on-line  testing  is  conducted  so  that  it  will 
not  affect  the  operation  of  the  system,  and  if  a  fault  is 
detected,  the  I/O  module  will  report  the  fault  to  the  system 
test  handler.  All  of  the  I/O  modules  can  be  accessed  across 
the  iPSB  bus  and/or  the  Controller  module's  Local/Dual  Port 
bus  to  further  increase  reliability  and  capability.  The  DIO 
module  contains  ninety-six  off/on  (zero  Volt/five  Volt) 
signals  which  can  be  used  to  control/monitor  switches,  etc. 
For  added  versatility,  these  signals  can  be  software 
configured  in  groups  of  eight  as  either  inputs  or  outputs. 
The  A/D  module  has  32  channels  for  converting  analog  input 
signals  into  digital  data  that  can  then  be  forwarded  to  one 


3.229 


of  the  processing  modules  for  interpretation.  The  D/A  module 
has  16  channels  on  which  digital  input  data  from  one  of  the 
processing  modules  can  be  output  as  analog  signals.  Both  the 
A/D  and  D/A  modules  have  pin  programmable  voltage  ranges  to 
increase  versatility,  or  a  voltage  level  outside  these  ranges 
can  be  scaled  for  acceptance  by  a  signal  conditioning  module. 
In  addition  to  the  pre-programmed  operational  modes  of  each 
module,  all  of  the  I/O  modules  can  be  loaded  at  the  user's 
discretion  with  pre-processing  programs  to  condition  the  data 
before  transmission  to  the  processing  modules.  This 
additional  feature  allows  the  burden  of  signal  processing  to 
be  distributed  throughout  the  system. 

5.  CONCLUSION 

Since  Navy  platforms  will  increase  in  complexity  to  meet 
both  the  low  and  high  level  threats  of  the  future,  ship 
control  systems  must  provide  a  high  speed  multi-tasking 
environment  to  exploit  the  capabilities  of  emerging 
technologies.  These  control  systems  will  require  high  speed, 
real  time  processing  capability  to  analyze  sensor  data,  apply 
the  data  in  intricate  operational  algorithms,  and  return  the 
required  control  signals.  Advanced  control  systems  must  have 
high  data  throughput,  quick  response  times,  and  levels  of 
redundancy  and  fault  tolerance.  These  systems  must  also  be 
reliable,  cost  effective,  and  easy  to  maintain.  The  Navy 
Universal  Digital  Electronic  Controller  is  able  to  meet  all 
of  the  Navy  requirements  for  control  systems,  now  and  in  the 
future.  It  gives  the  flexibility  and  speed  in  control  and 
data  processing  that  high  complexity  systems  require.  The 
ease  of  implementation,  the  built  in  redundancy,  and  the  high 
level  of  testing  and  fault  isolation  in  a  NUDEC  allows  the 
construction  of  a  wide  range  of  high  complexity  control 
systems . 

END  NOTE 

Multibus  II,  iPSB,  iLBX  II  are  trademarks  of  Intel 
Corporation  and  its  affiliates. 
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ENHANCED  PROPULSION  CONTROL  BY  USING  AN 

ADVANCED  ENGINE  CONTROL  SYSTEM 

by  F.  Butscher 
and  M.  Muller 
MTU  Deutsche  Aerospace 


1.  ABSTRACT 

Propulsion  Control  has  a  major  importance  among  the  different  fields 
of  Ship  Control.  Many  complex  Propulsion  Control  Systems  (PCS)  have  been  de¬ 
veloped  in  the  past.  Most  of  them  are  exposed  to  the  same  problem:  The  in¬ 
terface  between  the  PCS-computer  and  the  conventional  equipped  propulsion 
engines,  with  their  mechanical  governors,  pneumatic  actuators  and  parallel 
cabled  sensors,  restrict  the  efficiency  of  the  entire  system. 

MTU,  known  as  a  manufacturer  of  Diesel  engines  and  Gas  turbines  cleared  away 
these  restrictions  for  its  own  and  other  PCS  by  developing  a  computerized 
Ingine  Control  System  (ECS),  which  covers  all  engine-related  control  func¬ 
tions  and  offers  an  adequate  interface  to  the  Propulsion  Control  System.  In 
addition  an  Integrated  Load  Profile  Recorder  supplies  the  PCS  with  informa¬ 
tions  about  "Life  Cycle  Consumption". 

The  paper  contains  a  treatise  of  the  various  tasks  of  the  Engine 
Control  Systems  the  different  approaches  of  the  interface  to  the  superior 
PCS  and  new  "Propulsion  Control"  features.  The  advantages  of  the  combination 
of  ECS  and  PCS  are  shown  in  3  different  examples: 

■  speed  boat  with  four  shaft  FPP-propulsion 

■  corvette  with  two  shaft  COOAO-CPP  propulsion 

■  frigate  with  two  shaft  C0006-CPP  propulsion. 


2.  INTRODUCTION 

The  Eropulsion  Control  System  incorporates  all  components  required 
for  propulsion  plant  control  and  regulation.  The  main  element  is  the  Remote 
Control  System  (RCS),  which  performs  all  of  the  important  control  functions 
automatically.  It  relieves  the  operating  personel  of  such  tasks  as  configu¬ 
ration,  control  and  supervision  of  the  propulsion  plant.  Furthermore,  in¬ 
correct  control  processes  are  eliminated  to  a  great  degree  and  the  propul¬ 
sion  plant  condition  is  diagnosed  continuously.  These  tasks  are  fulfilled  by 
the  RCS  in  conjunction  with  the  engine  mounted  subassemblies  such  as  sen¬ 
sors,  actuators,  etc.  (Fig.  1). 
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Electrical  and  functional  connection  of  the  RCS  to  the  engine  pe¬ 
ripheral  equipment  is  extremely  difficult  due  to  the  large  number  of  inter¬ 
faces  involved.  The  technical  possibilities  and  operational  reliability  of 
the  PCS  are  therefore  limited. 

The  solution  to  this  problem,  as  discussed  in  this  paper,  avoids  di¬ 
rect  connections  between  the  RCS  and  the  engine  peripheral  equipment  by  in¬ 
terposing  the  Engine  Control  System  which  performes  the  engine  and  gearbox 
specific  control  functions  (Fig.  2) 

3.  CONVENTIONAL  PCSs  AND  THEIR  DISADVANTAGES 

3.1  Matching  to  the  various  types  of  sensors  and  actuators 

There  are  no  binding  standards  for  sensors  and  actuators.  As  a  result 
the  manufacturers  of  diesel  engines,  gas  turbines,  gearboxes,  propellers, 
etc.  employ  a  great  variety  of  different  types  of  actuators  and  sensors.  The 
necessity  of  matching  the  system  to  this  conglomeration  of  subsidiary  equip¬ 
ment  makes  RCS  standardization  extremely  difficult.  Sensors  with  different 
functional  sequences  require  modification  of  the  RCS  interface  circuitry. 
The  software  must  also  be  adapted  to  each  type  of  sensor,  particularly  in 
the  linearization  and  normalizing  sub-routines. 

Adaption  to  the  actuators  is  even  more  difficult  as  two  additional 
factors,  i.e.  power  range  and  the  dynamic  characteristics,  must  be  taken  in¬ 
to  consideration.  The  latter  is  especially  critical  for  actuators  are  to  be 
operating  in  "closed-loop  control”  since  the  available  datas  are  in  many  ca¬ 
ses  insufficient  regarding  the  dynamic  characteristics. 

3.2  Signal  transfer  by  parallel  wiring 

Many  signals  have  to  be  transmitted  between  the  RCS  and  the  pro¬ 
pulsion  machinery.  Figure  1  shows  the  best  known  version.  To  date  this  has 
been  accomplished  by  parallel  wiring  using  the  "one  conductor  one  signal" 
principle.  Continuously  increasing  PCS  complexity  leads  to  more  conductors, 
and  connectors,  that  means  a  rise  of  costs  and  a  reduction  of  reliability. 

3.3  Insufficient  flexibility  and  stability  of  nechanical  or 
mechanical -hydraulic  speed  governors 

Conventional  centrifugal  governors  are  difficult  to  calibrate.  Many 
tiroes  the  adjustment  repeatability  is  poor  and  heavy  long-term  adjustment 
drift  is  to  be  expected.  This  undesireable  side-effect  must  be  detected  and 
rectified  by  the  RCS.  Adaptation  of  the  governor  parameters  as  a  function  of 
operational  conditions  is  hardly  to  achieve,  with  such  conventional  gover¬ 
nors  which  can,  under  certain  circumstances,  lead  to  an  oscillating  engine 
speed.  Extensive  RCS  measures  (anti-cyclic  speed  demand)  are  required  to 
suppress  such  effects. 
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4.  EN6INES  AND  THEIR  ELECTRONIC  CONTROL 


Engine  Control  System  have  been  developed  not  only  in  order  to  eli¬ 
minate  the  problems  described  in  the  previous  chapter  but  also  to  meet  the 
precise  control  requirements  inherent  to  the  new-generation  engines. 

4.1  Diesel  engines 

a.  Characteristics  of  state-of-the-art  diesel  technoloov 

The  last  8  years  have  brought  about  considerable  advances  in  the  de¬ 
velopment  of  fast-running,  high-perfomance  diesel  engines.  The  specific  po- 
wer-to-weight  ratio  has  been  improved  by  some  30%  without  involving  any  ap¬ 
preciable  change  to  the  basic  engine  components  or  dimensions.  This  advance 
has  been  achieved  by  two  innovations  in  the  field  of  exhaust  turbocharging, 
i.e.;  ■  sequential  turbocharging.  Figs.  3  +  4  and 

■  two-stage  turbocharging  in  conjunction  with  sequential  tur¬ 
bocharging. 

The  former  allows  a  considerable  torque  increase,  particularly  in  the  medium 
speed  range.  The  latter  allows  charge  air  pressures  up  to  approximately  5 
bar  (gauge).  In  order  to  avoid  impermissibly  high  combustion  pressures  due 
to  these  high  charge  air  pressures,  the  engine  compression  ratio  has  been 
reduced.  The  resultant,  initially  poor,  combustion  characteristics  in  the 
idle  and  low-load  operating  modes  have  been  returned  to  aceptable  levels  by 
a  series  of  measures,  the  most  important  being; 

■  Cylinder  bank  cutout 

Only  one  bank  of  cylinders  is  supplied  with  fuel 

■  Charge  transfer 

The  air  charge  in  the  non-firing  cylinders  is  transferred  to  the 
opposing  (firing)  cylinders  during  the  compression  stroke  which 
leads  to  a  temporary  rise  in  the  compression-ratio. 

■  Ch  irge  air  preheating 

■J^'ie  intercooler  is  supplied  with  temperature-regulated  engine  coo¬ 
lant  instead  of  seawater.  As  a  result,  the  charge  air  is  cooled  in 
the  high -load  range  and  heated  in  the  low- load  range. 

b.  Engine  Control  System  (ECS)  for  Diesel -engines 

These  new  features  of  the  advanced  engine-technology  require  an 
electronic  control  system  which  additionaly  must  cover  the  conventional  con¬ 
trol  requirements  as  speed  governor,  start  and  stop  sequences.  Therefore,  an 
adequate  technology  was  chosen:  a  microprocessor  based  hardware  in  a  rugge- 
dised  casing  in  order  to  be  mounted  in  the  engine  room.  As  shown  in  Figs.  S 
and  6  the  ECS-tasks  are  divided  into  governing-,  controlling-  safety-  and 
diagnostic  functions.  The  latter  became  more  and  more  important  during  the 
recent  years  and  is  mostly  named  guilt  In  Test  Equipment  or  Integrated  lest 
System.  Fig. 7.  In  addition  to  the  current  standard  procedures  for  detection 
of  malfunctions  and  hidden  irregularities,  this  subsystem  is  capable  of  cal¬ 
culation  and  storage  of  life-data.  Worthy  of  specific  mention  in  this 
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respect  is  the  ECS  "Running  Profile  Recorder".  Fig. 8.  This  is  an  array  of 
digits  covering  the  engine  performance  map  (fuel  rack  position  versus  engine 
speed).  This  unit  registers  the  number  of  seconds  the  engine  operates  in 
each  power  range.  Provided  the  appropriate  machinery-constructional  datas 
are  known  this  information  can  be  used  to  calculate  the  life-cycle  consump¬ 
tion  details. 

4.2  Gas  turbines 


Various  types  of  gas  turbines  were  prepared  and  installed  by  mtu  for 
marine  applications  in  the  past.  Even  an  ECS  for  gas  turbines  (ECS-GT25)  has 
been  developed  .  (Fig. 9)  This  unit  follows  the  philosophy  of  the  ECS  pre¬ 
viously  created  for  Oiesel  engines:  to  cover  all  control-,  governor-  and  su¬ 
pervision  functions  as  well  as  to  communicate  with  the  RCS  by  a  serial  link. 
Therefore  the  communication  to  the  RCS  Involves  only  minimum  effort  even 
with  CODOG  propulsion  system. 


5.  ACHIEVED  ADVANTAGES 
5.1  Interface  simplification 

The  new-generation  MTU  £ng1ne  £ontrol  System  (ECS)  allows  acquisition 
of  all  engine  and  gearbox  measured  data  which  are  then  standardized;  the 
operational  and  limit  values  are  calculated  and  stored  in  a  data  memory. 
This  data  pool  is  available  to  the  superior  RCS  and,  if  necessary,  to  the 
Monitoring  Control  System  (HCS).  Data  transfer  is  via  physicaly  separated, 
bi-directional  data  links  or  bus  systems  which,  if  required,  are  designed  as 
redundant  systems.  To  date  RS-422  interfaces  have  been  preferred;  connection 
to  an  ETHERNET-bus  is  currently  under  test. 

The  roundabout  route  via  pneumatic  or  hydraulic  auxiliary  systems  is 
no  longer  necessary.  Interface  and  data  transfer  problems  have  been  elimina¬ 
ted.  The  amount  of  wiring  required  between  the  propulsion  system  components 
and  the  RCS  has  been  reduced  to  approximately  10%  of  that  originally  requi¬ 
red. 


5-2  Storage  and  presentation  of  engine  operating  and  diagnostic  data 

The  simplified  interface  to  the  ECS  has  the  advantage  that  all 
engine-related  data  and  the  "Load  Profile  Recorder"  integrated  into  the  ECS 
have  access  to  the  RCS,  and  MCS,  master  data  bases  located  in  the  main  con¬ 
trol  room  or  on  the  bridge.  All  data  are  permanently  stored  in  these  data 
bases  and  are  prepared  to  be  displayed  either  on  a  screen  (Fig. 10)  or  dialo¬ 
gue  unit. 
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5.3  PCS  Improvement  possibiUtics 


As  a  matter  of  principle  It  Is  possible  to  say  that,  due  to  the  In 
telUgent  ECS  systems  the  performance  capacities  for  modern  propulsion  sy 
stems  have  been  Increased  considerably. 

Here  are  a  few  examples: 

■  Optimum  power  matching  of  several  shaftllnes  (see  6.1). 

■  Power  matching  during  course  change  operation  (see  6.1). 

■  Optimum  power  matching  for  DAD  systems  by  simple  changeover 
from  master  mode  (speed  governor)  to  slave  mode  (fuel  injection 
governor)  (see  6.2). 

■  Schedule  map  correction  as  a  function  of  static  and  dynamic  po¬ 
wer  llmUatlon  due  to: 

Intake  air  temperature  according  to  ISO  3046/1 
Seawater  temperature  according  to  ISO  3046/1 
Fuel  temperature 
Charge  air  pressure 
(see  6.3). 

■  Optimization  of  acceleration,  I.e.  load  acceptance  control  with 
optimum  torque  development  (e.g.  CPP  propulsion  Fig. 11). 

Fig. 11  shows,  the  acceleration  characteristics  of  a  PCS  with 
and  without  "load  control".  In  the  case  of  propulsion  systems 
without  ECS  the  lack  of  reliable  signals  often  means  that  only 
time-dependent  specified  setting  commands  can  be  given  to  the 
propulsion  engine  and  the  CPP.  The  result  is  not  sufficient. 
Either  the  acceleration  ramp  is  very  slow  or  It  is  adjusted  to 
normal  conditions.  But  this  approach  would  lead  to  an  overload 
situation  If  a  change  appeared  in  enviromental  conditions,  i.e. 
hull  fouling.  Increased  displacement,  high  ambient  temperatures 
etc..  The  maneuver  Is  never  matched  to  the  best  conditions.  In 
the  case  of  MTU  propulsion  systems,  the  ECS  supplies  the  RCS 
with  a  qualified  signal  which  provides  information  on  the  power 
reserves  available  at  all  acceleration  phases.  This  information 
is  used  for  the  calculation  of  propulsion  engine  speed  and  pro¬ 
peller  pitch  settings.  This  results  in  optimized  acceleration 
and  crash  maneuvers  which,  irrespective  of  peripheral  condi¬ 
tions,  convert  the  maximum  possible  engine  power  into  pro¬ 
pulsive  thrust. 

■  Torsional  vibration  monitoring  with  alarm  initiation  and  Sche¬ 
dule  map  correction  if  alternating  torque  limit  is  exceeded 
(Fig.  12).  Due  to  external  influences  on  the  propeller,  or  pos¬ 
sible  engine  misfires,  torsion  vibrations  may  be  created  which 
can  endanger  the  propulsion  system  components,  especially  the 
coupling.  Fig.  12  shows  schematically  how  the  PCS  reacts.  Based 
on  its  "inside-information",  the  ECS  calculates  both  the  load 
torque  and  the  alternating  torque.  If  the  alternating  torque  or 
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the  total  torque,  exceeds  the  permitted  limit,  the  RCS  change 
the  “Demand"  signals  for  engine  speed  and  propeller  pitch  until 
the  excessive  torsional  vibration  (resonance  point)  is  passed 
over.  As  far  as  possible,  the  ship’s  speed  is  kept  constant  du¬ 
ring  this  procedure. 

■  Selection  capability  for  optimization  of  various  operational 
parameters,  such  as,  for  instance: 

Noise  reduction 
Fuel  consumption 

5.4  Development  and  test  simplification 

Employment  of  the  Engine  Control  System  has  considerable  advantages 
not  only  for  practival  in-ship  service  but  also  in  the  development  laborato¬ 
ry.  When  developing  and  testing  PCSs  it  is  not  necessary  for  each  and  every 
analogue  or  binary  value  to  be  available  as  hardware. The  serial  data  flow 
can  be  realized  using  an  original  ECS  or  an  personal  computer  for  simula¬ 
tion. 


6.  EXAHPLES 

6.1  Speed  boat  with  four-shaft  FPP  propulsion 

The  propulsion  system  configuration  shown  in  Figs.  13  and  14  com¬ 
prises  four  shaftlines  each  with  a  propulsion  diesel,  a  revers  reduction  ge¬ 
arbox  and  and  a  fixed-pitch  propeller.  Each  shaftline  is  controlled  by  an 
independent  RCS  using  identical  hard-  and  software.  The  number  of  control 
stands  can  be  extended  in  accordance  with  the  customer’s  options.  Each  pro¬ 
pulsion  engine  is  provided  with  its  own  ECS  and  is  serial  connected  to  the 
associated  RCS.  The  RCS  components  are  integrated  into  a  star  network  and 
the  information  interchange  from  shaftline  to  shaftline  is  also  via  serial 
data  links. 

In  addition  to  the  standard  PCS  tasks,  another  advantage  of  the 
RCS/ECS  constellation  is  worthy  to  mention.  Actuation  of  a  pushbutton  allows 
any  desired  shaftline  to  be  selected  for  "Single  Control  Lever"  operation. 
Under  cruise  conditions  this  considerably  eases  ship’s  handling,  in  order  to 
change  to  another  propulsion  stage  the  person  in  command  merely  has  to  ope¬ 
rate  one  lever  instead  of  four;  synchronisation  and  matching  of  all  shaftli¬ 
nes  is  assured  by  the  RCS.  The  ECS  provides  the  propulsion  system  with  up- 
to-date  performance  and  status  data  which  facilitates  precise  load  balancing 
between  all  four  shaftlines.  Propulsion  engine  overload  due  to  incorrect 
control  commands,  failure  of  one  shaftline,  uncoordinated  acceleration,  or 
deceleration  etc.  are  thus  prevented.  Even  during  course  change  ,  this  func¬ 
tion  prevents  unbalanced  engine  loading. 
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6.2  Friqate/Corvette  with  two-shaft  CODAD-CPP  propulsion 


Fig.  15 

The  propulsion  system  configuration  depicted  in  Fig.  15  comprises  two 
shaftlines,  each  with  two  propulsion  diesel  engines,  a  reduction  gearbox  and 
a  controllable  pitch  propeller.  Each  shaftline  is  controlled  by  an  indepen¬ 
dent  RCS.  Each  propulsion  engine  is  provided  with  its  own  ECS. 

Fig. 15  roughly  shows  the  interaction  between  an  ECS  per  engine  and 
the  RCS  as  referenced  to  one  shaftline.  A  particular  advantage,  inherent  to 
this  system,  is  the  effective  “Power  Sharing". 

Normally,  in  the  cruise  mode,  only  one  engine  is  operative  per  shaft¬ 
line.  By  pushbutton  actuation  in  the  control  stand,  this  engine  is  des¬ 
ignated  as  the  "Master"  engine  and  is  automatically  engaged.  For  the  asso¬ 
ciated  ECS  this  "Master"  designation  means  that  the  engine  governor  must 
operate  as  a  speed  governor  (Fig.  16  "Master  Control  Curve").  For  higher 
speeds  the  second  engine  is  required.  Again  by  pushbutton  actuation,  the 
operator  initiates  full  automatic  second  engine  synchronization  and  engage¬ 
ment.  On  completion  of  this  procedure  the  second  engine  ECS  receives  the 
designation  signal  "Slave"  and  switches  the  engine  governor  to  the 
fuel -injection  governor  mode.  (Fig.  16  "Slave  Control  Curve"). 

The  fuel  injection  governor  has  the  sole  task  matching  the  master 
engine  load  signal  within  the  permissible  speed  limits.  The  loads  per  engine 
are  thus  exactly  identical.  This  is  of  particular  importance  in  high-perfor¬ 
mance  applications  as  only  so  can  the  individual  engine  outputs  be  added  to¬ 
gether  to  produce  the  total  power  rating.  Pre-selection  of  the  "Master"  or 
"Slave"  engine  is  not  necessary  as  the  operator  can  freely  select  the 
"Master"  unit  under  all  operational  conditi  ons. 

The  design  and  concept  of  RCS  and  ECS  guarantee  precise  load  sha¬ 
ring,  not  only  for  static  operational  points  along  the  propeller  curve,  but 
also  for  dynamic,  or  transient,  procedures  such  as  occur  during  acceleration 
and  deceleration  manoevers  or  in  heavy  sea  conditions. 

If  the  operator  selects  the  "Single  Control  Lever"  function,  as  des¬ 
cribed  in  6.2  then,  once  again,  he  has  the  advantage  of  full  control  of  the 
ship’s  propulsion  system  via  a  single  control  lever. 

6.3  Frigate  with  two-shaft  CODOG-CPP  propulsion 

Fig.  17 

The  propulsion  system  configuration  depicted  in  Fig.  17  comprises  two 
shaftlines  each  with  a  propulsion  diesel  engine,  a  gas  turbine,  a  reduction 
gearbox  with  Self  Shifting  Synchronizing  Clutch  (SSSC)  and  a  controllable 
pitch  propeller.  Each  shaftline  is  controlled  by  an  independent  RCS.  Each 
propulsion  unit  is  provided  with  its  own  ECS.  Design  and  operation  of  this 
PCS  are  identical  to  the  previously  described  examples.  Again,  the  ef¬ 
ficiency  of  the  RCS  and  ECS  guarantees  excellent  handling  with  this  propul¬ 
sion  system  configuration. 
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Fig.  18  demonstrates  one  advantages  of  the  interface  simplification 
mentioned  in  5.1  using  the  ambient  temperature  compensator  as  an  example. 

The  ECS  measures  the  power-relevant  ambient  temperature  and  transmits 
the  measured  value  to  the  RCS.  Dependent  upon  which  propulsion  unit  is  cur¬ 
rently  active,  i.e.  diesel  engine  or  gas  turbine,  the  appropriate  functions 
are  initiated  to  which  the  demand  signals  are  then  matched.  For  the  gas  tur¬ 
bine  a  coefficient  is  calculated  from  the  manufacturer’s  performance  map 
which,  when  multiplied  by  the  temperature,  produces  a  corrected  demand  si¬ 
gnal.  The  ship’s  speed  preselected  by  the  operator  in  the  control  stand  re¬ 
mains  unchanged. 


7,  SUHMARY 

The  propulsion  control  is  enhanced  by  the  combination  of  the  Remote 
Control  System  with  an  advanced  Engine  Control  System.  The  following  advan¬ 
tages  are  achieved; 

■  Increase  of  Propulsion  Control  performance 

■  Increase  of  Propulsion  Control  reliability 

■  Reduction  of  ingeneering  efforts 

■  RCS-evaluation  by  simulated  machinery  under  real  time  conditions. 
Modern  engine  technology  combined  with  state  of  the  art  electronic  control 
offer  a  multitude  of  possibilities  for  layout  and  operation  of  power  plants 
in  order  to  provide  optimized  and  reliable  propulsion  with  full  considera¬ 
tion  of  the  technical  specifications,  safety  requirments  and  economy  as¬ 
pects. 
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NEW  CONTROLS  FOR  THE  POLAR  8TRR  AND  POLAR  SEA  ICEBREAKERS 


by  Guy  Hardwick 
TAMO  Marine  Systems,  Inc. 


1.  ABSTRACT 


U.  S.  Coast  Guard  polar  class  icebreakers  POLAR  STAR 
(WAGB  10)  and  POLAR  SEA  (WAGB  11)  were  built  in  the 
mid-seventies.  The  Coast  Guard  has  experienced  problems 
regarding  reliability  and  maintainability  with  the  original 
control  system.  The  original  system  supplier  is  no  longer  in  the 
marine  controls  business  which  has  made  spare  parts  supply  a 
difficult  task.  Recognizing  the  need  to  improve  the  situation, 
the  Coast  Guard  embarked  upon  a  course  to  change  out  the 
controls,  developing  a  specification  in  the  mid-eighties. 

TANO  won  a  contract  in  1987  to  remove  the  existing  control 
consoles  from  both  ships  and  install  new  distributed 
microprocessor  control  and  monitoring  systems  compliant  with 
MIL-P-24423  as  well  as  latest  military  technologies. 

Several  new  control  instruments  were  developed  under  this 
contract  to  meet  the  rigid  temperature  and  vibration  requirements 
experienced  during  icebreaking.  This  paper  describes  these  new 
devices  plus  other  unique  features  of  this  new  control  system, 
such  as  the  trackball/CRT  control  inputs,  and  Ada  software.  The 
paper  also  discusses  the  trade-off  studies  made  during  the  design 
process  to  achieve  a  high  degree  of  both  reliability  and 
maintainability. 

2 .  INTRODUCTION 

The  POIiAR  STAR  and  POLAR  SEA  icebreakers  were  launched  in 
1973  and  1975  respectively  at  Lockheed  Shipbuilding  in  Seattle, 
Washington.  These  ships  are  399  feet  long  and  are  the  largest 
icebreakers  outside  of  the  Soviet  Union. 

Propulsion  machinery  consists  of  Diesel -Electric  or  Gas  Tur¬ 
bine  (CODOG)  for  three  shafts  with  Escher  Wyss  controllable  pitch 
propellers.  There  are  six  main  propulsion  diesel  generators. 
Each  shaft  can  be  assigned  either  1  or  2  main  diesel  generators 
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to  obtain  either  3,000  or  6,000  hp  per  shaft  while  in  the 
electric  node.  Pratt  &  Whitney  gas  turbines  (model  FT4A12) 
provide  20,000  hp  (continuous  duty,  25,000  hp  surge)  for  each 
shaft.  Figure  2-1  shows  the  propulsion  plant  arrangement. 

In  diesel  electric  mode,  ALCO  diesel  engines  turn  AC  genera¬ 
tors.  The  output  is  rectified  to  DC  which  drives  Westinghouse 
propulsion  motors  which  turn  the  shafts.  In  gas  turbine  mode, 
the  free  turbine  output  shaft  drives  a  double-reduction  gear, 
which  is  coupled  to  the  propeller  shaft,  just  forward  of  the  DC 
propulsion  motors. 

The  propulsion  machinery  is  divided  among  five  machinery 
spaces:  Diesel  Room  No.  1  and  2,  Gas  Turbine  Room,  Hotor/Gear 

Room,  and  Motor  Room.  The  Motor  Room  contains  the  DC  motor  for 
the  centerline  shaft  as  well  as  the  CP  propeller  hydraulic 
systems  for  all  shafts. 

The  Engineering  Control  Center  Console  (ECCC)  is  located  in 
the  Engineering  Control  Center  (ECC)  directly  above  the  Motor 
Room. 

3.  8ZTDATZOM  AMALYSZ8 

The  following  is  a  brief  overview  of  the  system  being  re¬ 
placed.  The  original  monitoring  and  control  system  for  these 
ships  (built  by  Barber-Coleman)  was  a  hybrid  digital/hardwired 
design.  Refer  to  figure  3-1.  The  propulsion  control  and  moni¬ 
toring  was  hardwired  analog  electronics.  The  control  of  the 
electric  ship  service  and  auxiliary  systems  was  also  hardwired. 
The  monitoring  of  the  auxiliary  systems  was  done  by  a  computer. 
This  computer-based  system  provided  for  alarms  on  individual  in¬ 
dicators,  demand  displays  of  analog  parameters,  and  log  print¬ 
outs.  A  model  KSR-33  teletype  terminal  was  installed  in  the  rear 
of  the  control  console  for  running  diagnostics.  All  ship's 
sensors  were  wired  directly  to  the  ECCC. 

There  are  five  propulsion  control  locations:  primary  control 
from  the  ECCC  and  remote  control  at  the  Pilothouse  Console, 
Starboard  Bridge-wing  Console,  Port  Bridge-wing  Console,  and  the 
Aloft  Conning  Station.  The  aloft  conn  is  an  enclosed,  heated 
cubicle  located  on  the  mast  at  the  09  level.  Access  is  internal 
through  the  mast  structure.  Propulsion  and  steering  control  can 
be  transferred  from  the  Pilothouse. 

The  throttle  levers  at  the  pilothouse  were  mechanically 
linked  by  push-pull  cables  to  the  levers  at  the  port  and 
starboard  bridge-wing  consoles.  The  pilothouse  throttle  levers 
sent  analog  electric  signals  to  the  propulsion  control  system  in 
the  ECCC. 
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Figure  3-1.  Barber  Coleman  System 
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The  new  system  is  a  distributed  processing  system  incorpo¬ 
rating  five  RDUs  (remote  data  units) .  One  RDU  for  each  of  the 
five  machinery  spaces  (see  figure  4-1) .  The  system  features  nine 
militarized  VHEbus  processors  using  the  Motorola  MC68020  micro¬ 
processor.  The  contract  required  the  use  of  a  commercially 
available.  Industry  standard  processor  bus  using  two-part 
backplane  connectors.  VMEbus  and  Multi-Bus  II  both  met  the 
contract  requirements.  TANO  chose  VMEbus  based  upon  our  usage  of 
VHEbus  on  the  U.S.  Navy  T-AO  187  series  of  ships,  as  well  as  our 
Ada  programming  experience  with  the  Motorola  68000  series 
microprocessor.  TAMO  elected  to  design  our  own  family  of 
militarized  VMEbus  modules  because  some  features  required  (e.g. 
high-resolution  graphics)  were  not  available  elsewhere  at  the 
time.  We  also  felt  that  system  configuration  control  could  be 
better  managed  if  we  had  design  control  over  the  processors. 

5.  sons 

Each  RDU  contains  a  TANO  VME-68020  microprocessor  and  signal 
conditioning  electronics  to  acquire  and  send  data  to  the  sensors 
and  actuators  assigned  to  it.  This  system  uses  TANO's  military 
qualified  TDAC  (TANO  Data  Acquisition  and  Control)  sub-system 
which  performs  the  signal  conditioning  and  interfacing  to  the 
VMEbus  processor.  The  TDAC  sub-system  has  been  used  successfully 
on  U.S.  Navy  LSD-41  Class  ships  and  U.S.  Coast  Guard  WMEC-901 
Class  cutters. 

Each  machinery  space  also  has  one  or  more  local  panels  for 
visual  and  audible  alarm  indication.  Since  the  machinery  spaces 
on  these  ships  are  periodically  unmanned,  the  local  alarm 
acknowledge  will  automatically  silence  the  audible  horn  or  siren 
after  an  operator  enterable  time  delay. 

6.  ECCC 

The  ECCC  is  comprised  of  a  six  section  console,  each  section 
being  36  Inches  (91.4  cm)  wide.  For  EMI  protection  as  well  as 
protection  during  shipboard  assembly,  each  section  is  constructed 
as  an  individual  deck-mounted  console.  The  sections  are  bolted 
together  and  to  a  common  base  once  in  place.  The  construction 
also  lends  a  high  degree  of  independence  between  the  functional 
areas  of  propulsion  control,  auxiliary  control,  and  vital  alarm 
system . 


The  ECCC  contains  four  TANO  VME-68020  microprocessors,  one 
for  each  shaft,  and  one  for  the  ship  service  electric  plant  and 
auxiliary  systems. 
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Figure  4-1.  Machinery  control  alarm  and  monitroing  system. 
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Three  of  the  ECCC's  six  sections  are  devoted  to  PCAMS 
sub-systems  (Propulsion  Control  and  Monitoring  System) .  There  is 
a  separate  PCAMS  for  the  Starboard,  Port,  and  Centerline  shafts. 
Each  PCAMS  is  independent  of  the  other:  independent  power  input 
and  distribution,  redundant  DC  power  supplies,  VME  processor, 
local  interface  electronics,  CRT,  LCD  digital  meters,  throttle, 
trackball,  etc.  The  operator  can  control  and  monitor  the 
machinery  dedicated  to  a  given  shaft  or,  in  the  case  of  diesel 
generators,  assigned  to  that  shaft  (this  ship  system  allows  the 
operator  to  connect  an  alternate  DG  to  any  shaft  DC  motor  drive) . 
Except  for  nameplate  legends,  the  three  PCAMS  units  are  identical 
hardware  simplifying  maintenance  and  logistics.  Refer  to  figures 
6-1  and  6-2. 

a.  PCAMS  CRT  The  CRT's  used  on  the  PCAMS  and  the  rest  of 
the  TANO  system  are  military  grade  (MlL-E-16400)  high  resolution 
color  monitors.  The  resolution  is  800  x  600  pixels, 
non-interlaced.  The  CRT  is  fed  by  a  TANO  designed  VMEbus  video 
controller.  The  CRT  screen  is  divided  into  four  areas  (see 
figure  6-3) : 

o  Central  Display  Area 
o  Demand  Display  Area 
o  Message  and  Alarm  Area 
o  Sidebar  Menu  Area 

In  addition,  the  system  provides  pop-up  menus  for  specific 
purposes . 

The  normal  PCAMS  display  is  an  overview  mimic  of  the  respec¬ 
tive  shaft  showing  the  mode  (GT  or  DG)  and  supporting  systems. 
Refer  to  figure  6-4.  An  alarm  within  a  primary  system  will  lead 
the  operator  to  a  detailed  mimic  for  that  system  to  show  the 
operator  the  cause  for  the  alarm.  See  figure  6-5  for  an  example 
of  a  detailed  mimic. 

The  operator  can  select  any  three  analog  parameters  for  con¬ 
tinuous  display  (bar  graph  and  digital  format)  at  the  top  of  the 
CRT  screen  in  the  area  reserved  for  demand  displays. 

The  sidebar  menu  changes  with  the  central  display.  The 
sidebar,  together  with  a  trackball  controlled  cursor,  allows  the 
operator  to  activate  soft-keys  to  enter  commands  to  the  system  to 
bring  up  specific  mimics.  Detailed  mimics  allow  the  operator  to 
change  the  state  of  most  propulsion  auxiliaries  such  as  the  CPP 
servo  pumps. 

Example:  Frcsi  the  master  mimic  (figure  6-4),  the  operator 

would  move  the  cursor  to  the  "Pitch  Servo"  block  and  press  the 
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Figure  6-2.  PCAMS  control  surface 
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Figure  6-3.  Basic  display  format  for  mimic  display  pages. 


Figure  6-4.  Master  Mimic  Display  Page 


1 


Figure  6—5  Mimic  Display  Page 


SELECT  pushbutton  located  adjacent  to  the  trackball.  The  Main 
Motor/CPP  mimic  (figure  6-5)  would  appear.  The  operator  would 
see  the  status  of  the  CPP  servo  pumps.  If  the  operator  chose  to 
change  the  status,  he  would  move  the  cursor  to  the  servo  pump 
block  and  again  press  SELECT.  A  Pop-up  menu  (see  figure  6-6)  for 
the  servo  pumps  would  appear  on  the  screen  showing  the  operator 
which  choices  are  available.  By  using  the  cursor  and  the  SELECT 
pushbutton,  the  operator  can  change  the  pump's  status. 

Most  pumps,  valves,  heateris  and  other  propulsion  auxiliaries 
are  controlled  through  the  CRT  mimics  by  use  of  the  trackball 
cursor  and  a  pop-up  menu.  Those  auxiliaries  that  are  considered 
"critical"  are  also  available  (soft-key  commands)  on  a  Critical 
Controls  Page  which  the  operator  can  access  through  a  dedicated 
pushbutton  on  the  console. 

6.2  MBPMAS 


The  auxiliary  systems  monitoring  and  control  sub-system  is 
called  MEPMAS  (Main  Electric  Plant  Monitoring  and  Alarm  System) . 
The  hardware  elements  for  this  sub-system  are  identical  to  the 
hardware  items  used  in  the  PCAMS  (CRT,  trackball,  VME  processor, 
etc.)  except  that  the  MEPMAS  also  has  a  full  size  keyboard  to 
allow  the  operator  to  perform  system  utility  functions  such  as 
change  setpoints  and  time  delays,  load  new  software  from  magnetic 
tape,  and  modify  propulsion  control  variables. 

In  addition,  the  MEPMAS  includes  a  second  color  CRT, 
keyboard,  and  trackball  mounted  into  a  deck  mounted  unit  called 
the  Watchstander's  Terminal.  The  Watchstander's  Terminal  can 
simultaneously  display  different  data/mimics  than  the  ECCC 
mounted  MEPMAS  CRT.  This  unit  can  also  perform  as  a  back-up  to 
the  MEPMAS  CRT/keyboard/trackball.  The  MEPMAS  system  also 
contains  all  of  the  PCAMS  graphic  mimic  data  in  its  database  so 
that  in  the  event  of  a  failure  of  a  PCAMS  CRT,  the  MEPMAS  can  be 
set  by  the  operator  to  display  PCAMS  mimics  and  allow  the 
operator  to  activate  PCAMS  CRT  controlled  machinery. 

7.  LOCAL  AREA  NETWORK  (LAN) 

The  nine  VME  processors  communicate  with  each  other  over  a 
redundant,  high-speed  (10  Mb/s)  militarized  Ethernet  data  network 
in  conformance  with  ANSI/IEEE  Standard  802.3-1985  and  ISO 
International  Standard  8802/3.  (Ethernet  was  jointly  developed 
by  Digital  Equipment  Corp. ,  Intel  Corp. ,  and  Xerox  Corp.)  TANO 
designed  the  VMEbus  LAN  controller  and  the  bus  transceiver  (node) 
to  meet  the  military  requirements  for  shipboard  use. 
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Status  Parameter  Pop-Up  Menu  Format 


us  parameters, 


8.  VITAL  ALAKM  SYSTEM 


The  new  control  system  contains  an  Independent  vital  alarm 
system  (VAS) .  Refer  to  Figure  8-1.  The  VAS  is  based  upon  a  TANO 
designed  microcontroller  with  Read  Only  Memoiry  (ROM)  based  code. 
RAM  memory  is  used  for  time  delays  which  are  operator  changeable. 
The  VAS  has  its  own  set  of  redundant  DC  power  supplies  and  is  not 
affected  by  a  failure  of  the  main  control  system.  The  VAS  is 
linked  to  the  MEPHAS  to  allow  logging  of  vital  alarm  system 
events,  to  handle  the  man/machine  interface  for  time  delay 
changes,  and  to  allow  vital  alarm  annunciation  of  ECCC  PCAMS  or 
MEPMAS  VHE  processor  failure. 

9.  SOFTWARE 

The  language  that  was  chosen  for  this  system  is  Ada.  TANO 
chose  Ada  due  to  previous  success  with  Ada  on  a  US  Navy  auxiliary 
oiler  program. 

9.1  Random  Aeoess  Memory  (RAM)  Resident  Code 

An  important  software  maintenance  feature  is  the  use  of 
battery  backed-up  RAM  in  the  VME  processors.  The  RAM  modules 
have  an  on-board  battery  to  retain  memory  even  when  the  module  is 
removed  from  the  system.  The  software  is  downloaded  via  the  LAN 
to  each  of  the  nine  VME  sub-systems  by  use  of  the  magnetic  tape 
drive  system  linked  to  the  MEPMAS  processor.  The  system  allows 
the  logistics  of  spare  RAM  modules  to  be  simplified  and  the 
number  of  unique  electronic  modules  to  be  kept  to  an  absolute 
minimum. 

9.2  Software  Modules 


The  following  list  describes  the  various  Ada  modules  in  the 
Polar  Class  system: 

a.  Serial  I/O  -  contains  utilities  for  configuring  and 
communicating  with  devices  connected  to  the  TANO  VMEbus  Serial 
I/O  board. 

b.  Database  -  consisting  of  predefined  fields.  Database  is 
used  to  perform  data  acquisition,  runtime  calculation,  and 
display. 


c.  Network  -  provides  facilities  to  allow  for  general 
process-to-process  communication  over  the  LAN.  In  general,  the 
LAN  is  used  to  communicate  changes  or  exceptions.  This  reduces 
the  network  traffic  reducing  the  possibility  of  data  "collisions” 
and  subsequent  false  readings. 
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d.  Data  Acquisition  -  scans  raw  data  from  RDU  signal 
conditioning  electronics  (TDAC) ,  checks  for  alarm  and  fault 
states,  and  sends  output  commands  to  external  machinery  through 
TDAC  analog  and  solid-state  relay  outputs. 

e.  Display  -  provides  facilities  to  create  all  of  the  mimic 
display  pages,  update  the  analog  and  status  data  displayed  on  a 
CRT  screen,  bring  up  the  pop-up  menu,  and  display  setpoint 
values.  A  simple  off-line  facility  gives  the  user  the  ability  to 
create  mimic  layouts  on  a  personal  computer  (PC) . 

f.  Graphics  -  is  designed  to  interface  with  the  TAMO  VMEbus 
Video  Graphic  Controller.  The  Video  board  uses  the  Advanced 
Micro  Devices  AM95C60  graphic  engine.  Graphics  provides  routines 
for  interfacing  with  the  AM9SC60  chip  and  a  scaled  down  version 
of  the  GKS  graphics  command  set  plus  some  GKS_EXTENDED  commands. 

g.  Propulsion  Control  -  provides  the  various  routines  for 
controlling  the  shaft  rpm  and  pitch,  handling  control  location 
transfers,  interfacing  with  digital  throttles,  gas  turbine 
start-stop  seguence  logic,  diesel  generator  load  control,  etc. 
All  closed-loop  control  routines  are  confined  to  the  processor 
that  has  access  to  the  control  inputs  and  outputs  so  as  not  to 
add  a  time  phase  lag  because  of  multi-processor  and  IAN  handling. 

10.  TRAOE-OPF  STUDIES 

Several  design  trade  studies  were  done  during  the  course  of 
the  project  to  improve  the  system  performance,  reliability,  or 
operability.  A  few  are  described  here: 

10.1  CRT  Control 


Perhaps  the  most  significant  trade  study  involved  reducing 
the  number  of  discrete  motor/valve  controls  and  indicators  on  the 
ECCC  in  favor  of  using  software  via  the  CRTs  and  trackballs. 
This  had  the  effect  of  reducing  the  quantity  of  discrete  panel 
mounted  components  thereby  allowing  the  ECCC  to  be  physically 
smaller  and  less  intimating  to  the  operator.  Also,  less  hardware 
increases  the  reliability  of  the  system  with  corresponding  reduc¬ 
tions  in  logistics/ spare  parts  requirements. 

10.2  Digital  Meters 

Another  trade  study  involved  the  digital  and  circular 
bar-graph  meters  used  in  the  system.  The  original  specifications 
called  for  LED  meters.  Experiments  with  military-grade  LED 
meters  in  and  near  direct  sunlight  showed  that  readability  was 
not  satisfactory.  TANO  proposed  a  liquid  crystal  display  (LCD) 
meter  that  proved  to  be  usable  in  all  lighting  conditions 
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expected  on  the  bridge  of  the  icebreakers.  The  meters  used  on 
the  KCCC  are  the  same  type  (LCD)  for  logistics  reasons. 

10.3  Throttle  Wheel 


The  Coast  Guard  asked  that  we  eliminate  the  mechanical 
push-pull  cables  presently  used  on  the  bridge  to  link  the  ship 
control  console  (SCC)  throttle  levers  to  the  bridge  wing  levers. 
He  were  also  asked  to  keep  the  design  as  simple,  rugged,  and 
reliable  as  possible.  In  answer  to  this  challenge,  TANO 
developed  the  Digital  Throttle  Wheel  (DTW)  (see  figure  lo-l) 
which  communicates  over  a  RS-422  serial  link  to  its  corresponding 
PCAMS  unit  in  the  ECCC.  The  DTW  has  only  two  moving  parts  with 
no  physical  rotational  stops  and  uses  an  optical  encoding  device. 
The  design  of  the  throttle  device  allows  the  operator  to  command 
the  full  range  (from  maximum  astern  to  maximum  ahead)  while 
maintaining  contact  with  the  same  point  on  the  wheel.  At 
pilothouse  and  aloft  conn  stations,  the  operator  can 
simultaneously  control  three  throttle  wheels  with  two  hands. 

The  throttle  command  setting  is  displayed  in  digital  format 
on  an  LCD  display  adjacent  to  the  throttle  wheel.  All  control 
locations  display  the  exact  same  throttle  conunand  setting. 
Control  location  transfers  are  inherently  "bump-less"  since  all 
locations  track  the  controlling  location  commands  through  the 
data  links. 

11.  IH8TALLATIOH  CHALLENGE 

This  section  discusses  the  engineering  challenges  to  install 
the  new  system  (size  and  placement  of  RDUs,  size  of  ECCC,  etc.) 
The  contract  required  that  TANO  remove  and  replace  the  control 
system  while  the  ships  are  docked  and  the  crew  is  aboard. 

11.1  RDUS 

The  RDUs  had  to  be  sized  to  fit  through  existing 
passageways.  The  approach  taken  was  to  divide  the  RDU  into 
functional  boxes  of  manageable  size.  Each  RDU  consists  of: 

a.  Power  Box  containing  the  redundant  DC  power  supplies  and 
EMI  filters, 

b*  Electronics  Box  containing  the  TANO  VME-68020  processor 
and  TANO  Data  Acquisition  and  control  (TDAC)  electronics, 

c.  I/O  Box(s)  housing  the  field  termination  modules  and 
signal  conditioning  circuits. 
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The  boxes  are  mounted  as  close  to  each  other  as  possible  and 
inter-box  wiring  is  protected  by  means  of  EMI  shielded, 
splash-proof,  stainless  steel  wire  ways. 

Existing  sensor  cables  were  removed  and  new  low-smoke  cables 
installed  from  the  sensors  to  the  RDUs.  Cabling  from  RDUs  to  the 
ECCC  do  not  transit  other  machinery  spaces  to  limit  system 
degradation  due  to  a  casualty  in  any  one  machinery  space. 

11.2  BCCC 

The  ECCC,  as  previously  mentioned,  has  the  appearance  of 
having  six  sections.  Actually,  the  ECCC  has  twelve  sections. 
Each  major  section  (Port  PCAMS,  Stbd  PCAMS,  MEPHAS,  etc.)  is 
composed  of  a  front  and  rear  section  bolted  together.  This  was 
done  to  allow  easier  transit  of  sections  into  the  control  room. 

All  wiring  enters  the  ECCC  from  the  top  surface  of  the 
console  since  the  space  below  the  ECCC  is  the  Motor  Room 
machinery  space  (not  allowed  to  run  wires  through  a  machinery 
space  that  do  not  originate  or  terminate  in  that  space) . 

12 .  80MMART 

As  this  paper  is  written,  the  Polar  Star  Class  (400  WAGE) 
control  system  is  undergoing  first  article  qualification  testing. 
Installation  of  the  first  ship  system  is  scheduled  for  November 
of  1990. 

The  following  is  a  recap  of  some  of  the  features  of  this 
advanced  system: 

-  Distributed  processing, 

-  MC68020  militarized  VMEbus  processors  (quantity  9) , 

-  Redundant  militarized  Ethernet  Local  Area  Network, 

-  Ada  software, 

-  High  resolution  19-inch  (48  cm)  color  CRTs  (quantity  5) , 

-  Trackballs  and  advanced  "soft-key"  CRT  control  design 

provide  greater  reliability  and  commonality  of 

hardware , 

-  Liquid  Crystal  Display  digital  and  bargraph  meters  for 

readability  in  bright  light, 

-  LED  lamps  in  lieu  of  Incandescent  in  status/alarm 

indicators  for  reliability, 

-  Advanced  throttle  wheels  providing  precise  digital 

control  for  three  shafts  at  five  different  locations, 

-  Built  and  documented  to  military  standards  (MIL-P-24423) , 

-  Monitors  and  controls  approximately  1,000  analog  and 

digital  parameters. 
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The  new  TANO  control  system  meets  the  needs  for  high 
reliability  and  improved  maintainability  for  military 
environments.  In  addition,  this  design  lends  itself  to  easily 
adding  future  upgrades  such  as  adding  additional  sensors  or 
incorporating  on-board  operator  training. 
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1.  ABSTRACT 

A  Rudder-Roll  Stabilization  system  is  described  in  this 
paper.  The  system  is  microcomputer  based  and  contains  an 
adaptive  Kalman  filter,  an  adaptive  course-keeping  autopilot, 
high-gain  turning  regulators  and  an  adaptive  roll  damping 
regulator.  Roll  measurements  made  onboard  a  minelayer,  an  attack 
craft  and  a  passenger  vessel  show  that  the  roll  reductions 
obtained  with  the  ROLL-NIX  system,  are  of  the  same  order  as  those 
which  can  be  expected  with  an  active  fin  stabilizing  system.  It 
the  requirements  on  roll  damping  are  extremely  high,  ROLL-NIX  and 
active  fins  can  be  used  at  the  same  time.  The  ROLL-NIX  system  is 
in  service  on  several  ships  including  both  naval  and  merchant 
ships.  Both  operational  experience  and  the  results  of  tests  are 
presented . 

2 .  INTRODUCTION 

During  recent  years,  interest  in  Rudder-Roll  Stabilization 
(RRS)  has  increased  rapidly.  Advanced,  adaptive  filter  and 
control  algorithms  for  roll  damping,  course  maintenance,  turning 
and  track -keeping  are  easily  implemented  in  microcomputers.  On 
many  types  of  ship  the  RRS  technique  gives  roll  reductions  in  the 
same  order  as  active  stabilizing  fins. 

The  application  of  rudder  roll  stabilization  systems  has 
moved  to  include  merchant  and  commercial  vessels  along  with  the 
well  documented  applications  aboard  naval  vessels.  Common^  among 
the  characteristics  desired  in  these  newer  applications  is  the 
need  or  desire  to  maintain  the  vessel's  top  speed,  maximum  draft, 
and  fuel  efficiency.  In  short,  the  characteristics  of  RRS 
systems  highly  valued  for  naval  applications  are  important  for 
merchant  and  commercial  applications  as  well. 

The  process  of  introducing  sophisticated  control  algorithms 
to  vessel  steering  systems  makes  obvious  the  need  and  opportunity 
to  address  other  areas  of  the  ship's  steering  processes.  In 
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particular,  areas  traditionally  kept  separate  and  distinct  aboard 
ships  such  as  rudder  movement,  autopilot,  course  planning, 
charting,  and  navigation,  may  now  be  integrated  in  a  manner 
consistent  with  the  real  needs  of  the  bridge  crew.  This  new 
reality  is  possible  by  means  of  the  integrated  circuit 
microprocessor.  Complex  control  algorithms  based  upon 
sophisticated  algorithms  can  now  be  implemented  reliably  in  small 
packages . 

The  ROLL-NIX  system  is  an  example  of  the  application  of  this 
new  technology;  it  provides  a  sophisticated  rudder  roll 
stabilization  algorithm  for  the  realization  of  its  primary 
mission,  roll  damping.  In  addition,  however,  its  ancillary 
systems:  autopilot,  precise  turning  regulator,  and  course  keeping 
alarms  provide  substantive  support  to  the  vessel's  steering 
activities  on  the  bridge.  Possibilities  extend  well  beyond  what 
is  presented  in  this  paper.  Our  intent  is  to  show  that  careful 
holistic  planning  can  yield  a  significant  advance  in  the  state  of 
the  art  by  integrating  several  systems  previously  kept  separate 
and  using  the  shared  knowledge  to  substantially  improve  a  ship's 
operations . 

2.1  Review  of  RRS 

The  concept  of  utilizing  the  rudder  for  the  purpose  of 
stabilizing  a  vessel  against  rolling  has  been  known  since  ancient 
times  by  seafarers.  The  interest  for  designing  an  automatic 
control  system  for  KRS  started  around  1970.  See  Cowley  and 
Lambert  [1].  The  first  sea  trial  attempts  performed  in  U.K.  were 
not  always  successful  [2],  [3],  [4],  mainly  due  to  the  fact  that 
simple  control  systems  based  on  analogue  techniques  were  used. 

In  the  beginning  of  the  eighties,  very  interesting  and 
promising  results  were  obtained  in  USA  by  Baitis  and  co-workers 
[5],  [6].  A  survey  of  RRS  in  the  U.S.  Navy  is  given  in  [7]. 

The  RRS  developments  in  Holland  are  summarized  in  [8],  [9] 
and  [10].  A  Danish  RRS-system  is  described  in  [11]. 

The  development  of  the  Swedish  system  ROLL-NIX  started  in 
1984,  see  [12]  and  [13].  The  first  commercial  ROLL-NIX  was 
installed  in  1987.  By  the  end  of  1990,  the  number  of  installed 
ROLL-NIX  systems  will  be  in  the  range  of  10  to  15. 

2^ _ Integration  of  RRS  and  Autopilot 

since  the  steering  gear  and  rudder  system  is  used  both  for 
ship  maneuvering  and  roll  reduction,  the  integration  of  RRS  and 
autopilot  functions  into  a  single  control  system  is  of  crucial 
Importance.  This  has  been  discussed  in  many  papers,  see  e.g. 
[2],  [3],  [8],  [13],  [14]  and  [15]. 
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2.3  Organization  of  Paper 


Section  3  describes  the  ROXiL-NIX  system.  The  system  design 
includes  the  Kalman  filter,  the  autopilot,  the  turning  regulator 
and  the  roll  damping  regulator;  each  are  reviewed.  A  description 
of  the  hardware  implementation  is  given  in  Section  4. 
Experiences  from  sea  trials  are  given  in  Section  5,  and  a  summary 
of  operational  experiences  can  be  found  in  Section  6.  The 
conclusions  are  summarized  in  Section  7,  followed  by  the 
acknowledgements  and  references  sections. 

3.  THE  ROLL-HIX  SYSTEM 

SSPA  started  the  development  of  ROLL-NIX  in  1984. 
Presently,  in  1990,  more  than  ten  systems  are  running  on  ships 
around  the  world.  There  are  ROLL-NIX  installations  on  many 
different  ship  types,  e.g.: 

-  attack  craft 

-  mine  layer 

-  coast  guard  cutter 

-  rescue  vessel 

-  passenger  vessel 

The  compiled  experience  of  ROLL-NIX  in  operation  covers  more  than 
eight  years  (April  1990} .  The  system  is  certainly  well-proven 
and  the  installations  provide  their  respective  ships  significant 
reductions  in  roll.  ROLL-NIX  is  designed  for  use  together  with 
standard  steering  gear  and  rudder  systems.  Normally  the  maximum 
rudder  rate  is  between  3  deg/s  and  10  deg/s  when  two  pumps  are 
used  at  the  same  time. 

A  photograph  of  the  complete  system  is  shown  in  Figure  1. 
The  size  of  the  computer  unit  is  0.6  x  0.22  x  0.4  m  and  of  the 
control  panel  0.375  x  0.17  x  0.12  m.  The  total  weight  is  only  25 
kg. 


3-.1  System  Design 

The  ROLL-NIX  system  contains: 

-  Adaptive  Kalman  filter 

-  Adaptive  course-keeping  autopilot 

-  High-gain  turning  regulators 
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-  Adaptive  roll  damping  regulator 

The  course  and  speed  signals  to  ROLL-NIX  are  taken  respectively 
from  the  ship's  course  gyro  and  speed  log.  Both  the  rudder 
position  and  the  position  of  the  helmsman's  wheel  are  also 
obtained  so  that  the  ROLL-NIX  function  can  be  provided  while  the 
ship  is  being  steered  manually.  The  roll  rate  is  measured  with  a 
built-in  solid  state  rate  gyro.  A  block  diagram  of  the  system  is 
shown  in  Figure  2. 


Figure  1.  The  ROLL-NIX  system. 
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Figure  2.  ROLL-NIX  block  diagram. 
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3.2  Adaptive  Kalman  Filter 


The  signal  from  the  roll  rate  sensor  is  processed  by  an 
adaptive  Kalman  filter.  Smooth  estimates  of  the  roll  rate,  the 
roll  acceleration  and  the  roll  frequency  are  obtained  and  fed  to 
the  roll  damping  regulator. 

1. 3  Adaptive  Course-Keeping  Autopilot 

The  adaptive  autopilot  is  used  for  steady  state  course¬ 
keeping  and  minor  turns,  i.e.  course  changes  less  than  about  ten 
degrees.  The  self-tuning  regulator  concept,  see  [18],  is  the 
basis  of  the  autopilot.  A  detailed  description  is  given  in  [16] 
and  [17]. 

The  main  feature  of  the  autopilot  is  its  completely  adaptive 
control  algorithm.  This  means  that  the  controller  is 
automatically  adjusted  when  the  wind  and  wave  conditions  vary,  or 
the  trim  and  load  conditions  of  the  ship  are  changed.  The 
autopilot  always  controls  the  vessel  in  a  way  that  optimizes  fuel 
consumption. 

3.4  High-Gain  Turning  Regulators 

A  set  of  high-gain  turning  regulators  is  used  in  the  ROLL- 
NIX  system  for  precise  and  controlled  turns.  The  regulators  are 
described  in  [16]  and  [17]. 

The  operator  enters  the  required  turning  radius  using  a 
button  on  the  control.  He  starts  the  turn  by  moving  the  joystick 
in  the  desired  turn  direction.  (See  Figure  1.) 

3.5  Adaptive  Roll  Damping  Regulator 

The  roll  damping  regulator  is  designed  in  such  a  way  that  a 
prediction  of  the  ship's  roll  motion  is  calculated  based  on  the 
Kalman  filter  estimates.  From  these  estimates  a  control  signal 
is  generated  for  counteraction  of  the  roll  motion.  The  regulator 
is  adaptive  and  designed  for  optimum  roll  damping  when  the 
maximum  rudder  rate  is  in  the  minimal  range  of  3  to  10  deg/s. 
The  inclusion  of  roll  motion  prediction  assures  that  an  excellent 
roll  damping  is  achieved  even  though  the  maximum  rudder  rate  is 
less  than  10  deg/s. 

The  adaptive  roll  damping  regulator  is  designed  for  use 
during  steady  state  course-keeping  and  normal  turns.  During 
tight  turns  or  evasive  actions  the  roll  damping  regulator  is 
automatically  switched  off. 
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4. 


HARDWARE  IMPLEMENTATION 


ROLL-NIX  Is  implemented  as  a  system  of  modular  subsystems 
Interconnected  by  an  industry  standard  bus,  the  VMEbus  standard. 
This  structure  has  supported  the  design,  prototyping,  field 
testing,  and  manufacturing  production  of  this  system  for  all  of 
its  phases  to  date.  The  advantages  of  this  approach  include: 

-  Availability  of  components  from  many  sources. 

-  The  ability  to  include  custom  components  or  interfaces  on 
an  interchangeable  plug-in  module  basis. 

-  Ability  to  perform  most  field  service  operations  at  the 
module  level  as  opposed  to  the  circuit  diagnosis  level. 

-  Convenience  in  upgrading  of  either  the  algorithm(s)  or 
addition  of  new  features. 

The  following  sections  discuss  the  hardware  components  of 
ROLL-NIX  in  this  modular  context. 

4.1  The  Microcomputer  System 

VMEbus  equipment  is  readily  available  from  several 
commercial  sources.  Equipment  enclosures  that  meet  the  size, 
ruggedness,  and  esthetic  requirements  for  use  on  a  ship's  bridge 
where  space  is  becoming  an  increasingly  precious  commodity, 
however,  are  more  sparsely  available.  The  enclosure  chosen  for 
ROLL-NIX  contains  two  sets  of  hinges  to  allow  access  to  both  the 
front  and  rear  of  the  VME  backplane  and  modules  via  the  front 
door  of  the  cabinet.  This  particular  enclosure  has  the 

possibility  of  being  completely  sealed  (watertight)  to  NEMA  12 
specifications  if  a  heat  exchanger  was  used  rather  than  the 
presently  used  forced  air  cooling. 

a.  VMEbus  microcomputer.  The  microcomputer  module  is  a 
Motorola  MVMEIOI  single  board  system.  Additional  modules,  an 
analog  -  digital  -  analog  conversion  module,  a  battery  backed  RAM 
module,  and  I/O  interface  modules  complete  the  system. 

b.  Control  panel.  The  control  panel  connects  to  the  system 
via  an  I/O  module  which  provides  isolation  and  cable  driving 
circuitry  (see  Figure  1) .  The  panel  is  thus  mounted  separately 
at  a  site  convenient  to  the  helm.  The  production  version  of  the 
panel  has  been  carefully  designed  to  be  convenient  for  the 
professional  operator.  Buttons,  levers,  and  indicators  have  been 
arranged  for  clear  and  concise  communication  between  the  operator 
and  the  system. 
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c.  Roll-rate  sensor.  The  roll-rate  sensor,  a  solid-state 
gyro,  is  not  significantly  affected  by  translational  velocities 
or  accelerations.  This  means  that  it  may  be  mounted  nearly 
anywhere  provided  that  its  axis  of  rotational  sensitivity  is 
parallel  with  the  ship's  axis  of  roll.  This  convenient  property 
allows  the  sensor  to  be  mounted  in  the  system  cabinet  as  a 
module.  Provision  has  been  made  in  the  sensor  module  for 
mechanical  adjustment  of  the  sensor's  axis  to  achieve  parallel 
alignment  with  the  ship's  axis  of  roll. 

d.  Tuning  of  the  system.  Best  performance  of  the  ROLL-NIX 
system  is  achieved  by  adjusting  or  tuning  several  parameters 
which  optimize  the  model  of  the  ship's  roll  damping  to  actual 
measured  characteristics.  In  addition,  several  ship's  model 
parameters  used  by  the  autopilot,  precise  turning  regulator,  and 
alarm  algorithms  must  be  made  available  to  the  system.  A  set  of 
adjustment  programs  and  diagnostic  procedures  are  accessible  via 
a  connector  on  the  system's  panel.  The  system  is  tuned  by 
connecting  a  portable  terminal  to  access  the  interactive 
adjustment  program.  The  coefficients  and  parameters  are  stored 
and  recalled  from  the  battery  backed  RAM  portion  of  system 
memory . 


e.  Cabinet  and  power  supply.  Excepting  the  control  panel, 
all  system  modules  and  interfaces  are  enclosed  in  the  computer 
cabinet.  Included  there  is  the  power  control  circuitry  and  a 
modular  commercially  available  power  supply  for  the  provision  of 
the  standard  DC  voltages  required  by  VMEbus  systems. 

4.2  Interfaces  to  Vessel  Systems 

The  ROLL-NIX  system  incorporates  individual  I/O  interface 
modules  for  connection  to  other  shipboard  devices  and  systems. 
These  modules  provide  electrical  isolation  as  well  as  the  data 
formatting  capability  needed  to  acquire  or  dispense  data  in  forms 
useful  to  all  devices  so  connected.  The  following  sections 
describe  the  principal  Interfaces  and  some  of  the  optional 
interfaces: 

a.  Steering  gear  interface.  Depending  upon  the  type  of 
steering  control  used  by  the  ship,  non-follow  up  or  full-follow 
up,  _  the  steering  control  interface  board  is  selected  and 
configured.  This  includes  input  from  a  rudder  position  sensor 
and  the  ship's  wheel. 

llj _ Gvro  compass  interface.  An  Interface  to  gyro  compass 

signals,  or  optionally  to  a  flux  gate  compass  if  a  gyro  compass 
is  not  available,  is  provided.  As  an  option,  a  visual  readout  of 
heading  can  be  provided  to  a  point  close  to  the  ROLL-NIX  control 
panel. 
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c.  Optional  interfaces.  Interfaces  to  course  planning 
systems  attached  to  SatNav  or  GPS  are  available  on  a  custom  order 
basis.  The  ability  to  interface  with  other  equipment  makes 
possible  increased  integration  of  bridge  operations. 

5.  EXPERIENCES  FROM  SEA  TRIALS 

The  performance  of  roll  damping  systems  has  been  measured  in 
different  ways  over  the  years.  From  the  scientific  point  of 
view,  the  obvious  approach  is  to  measure  the  roll  angle  with  and 
without  the  roll  damping  system  activated  during  exactly  the  same 
conditions.  The  significant  roll  angle  *i/p  or  the  rms  value  is 
then  calculated,  and  the  percentage  reduction  obtained  with  the 
roll  damping  system  is  calculated  as: 


Reduction  (%) 


*1/3  (with  roll  damping) 
*1/3  (without  roll  damping) 


X  100  (5.1) 


This  is  the  method  used  in  this  paper  for  discussion  of  the  roll 
damping  performance  of  ROLL-NIX.  For  comparison,  the  typical 
reduction  in  roll  motion,  calculated  by  (5.1),  is  50-70%  for 
active  fin  stabilizers.  LLoyd  [19]  (p  349)  claims  that  for 
active  fin  systems  "Reductions  in  rms  roll  motion  of  at  least  50% 
are  usually  possible  in  moderate  waves  with  a  well  designed 
system" . 

Sometimes  another  method  is  used,  especially  for  active  fin 
systems,  to  estimate  the  roll  reduction  with  a  roll  damping 
system.  A  Wave  Slope  Capacity  (WSC)  is  calculated  and  a  typical 
roll  reduction  is  obtained  for  a  very  special  case,  namely 
completely  regular  sea  and  synchronized  control.  A  typical  roll 
reduction  for  active  fins,  calculated  in  this  way,  is  in  the 
range  of  80  to  90%.  If  the  same  method  is  used  to  calculate  the 
roll  reduction  obtained  with  a  RRS-system,  almost  the  same 
figure,  in  the  range  of  80  to  90%,  is  obtained. 

It  is  important  to  remember  that  a  roll  reduction 
calculation  done  in  this  way  does  not  reflect  what  will  happen 
under  irregular  sea  conditions.  It  does  not  consider,  for 
Instance,  the  quality  of  the  control  system. 

5.1  Roll  Decay  Test 

In  order  to  design  a  good  RRS-system  for  a  specific  ship  it 
is  Important  to  get  information  about  the  ship's  roll  dynamics. 
A  simple  approach  is  to  move  the  rudder  in  a  sinusoidal  way  with 
a  frequency  close  to  the  ship's  roll  frequency,  and  record  both 
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rudder  angle  and  roll.  This  ne'fchod  gives  a  rough  estimation  of 
how  much  damping  can  be  achieved  with  a  BRS-system,  since  such  a 
system  works  exactly  the  other  way  around. 

The  test  described  above  can  be  extended  in  such  a  way  that 
the  rudder  is  moved  to  zero  when  the  ship  is  steadily  rolling,  or 
for  comparison,  the  RRS-system  is  activated  Instead  of  moving  the 
rudder  to  zero.  An  example  of  this  type  of  test  is  shown  in 
Figure  3. 

It  can  be  concluded  for  this  type  of  ship,  a  passenger 
vessel  60  m  long,  that  the  ROLL-NIX  system  is  very  effective,  at 
least  when  the  ship  is  rolling  close  to  the  ship's  o%m  roll 
frequency. 


Table  1.  Summary  of  measured  roll  reductions  with  ROLL-NIX  (see 
(5.1))  for  the  minelayer  HMS  Carlskrona  (L  =  105  m) . 


Test  No. 

Sea  state 

Wave  direction 
[deg] 

Speed 

[knots] 

Roll  reduction 

1.1 

4 

90 

15 

40% 

1.2 

4 

50 

15 

50% 

2.1 

5 

50 

17 

41% 

2.2 

5 

130 

14 

45% 

2.3 

4 

90 

16 

68% 

3.1 

5-6 

20 

14 

33% 

3.2 

5 

30 

14 

46% 

3.3 

6 

70 

15 

47% 

3.4 

5 

40 

-  -  -  —  — 1 

13 

40% 

Wave  direction:  0  degrees  -  astern  seas. 


?i2  Minslaygr  HHS  carlgKronfl 

The  minelayer  HMS  Carlskrona  of  the  Royal  Swedish  Navy  got 
the  first  commercial  ROLL-NIX  installation.  This  system  has  been 
in  operation  for  almost  three  years.  The  roll  damping 
performance  with  ROLL-NIX  has  been  measured  in  different  sea 
conditions  and  at  different  ship  speeds  using  (5.1).  A  si^mraary 
is  given  in  Table  1.  It  can  be  concluded  that  in  normal 
conditions  a  roll  damping  in  the  order  of  40-50%  is  achievable 
with  ROLL-NIX,  but  the  maximum  roll  reduction  obtained  was  as 
much  as  68%. 
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Figure  3.  Roll  decay  test  in  calm  seas  with  and  without  ROLL-NIX 
on  a  passenger  vessel  (L  «  60  m)  at  a  speed  of  16 
knots. 
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Figure  4  shows  the  ROLL-NIX  performance  in  beam  seas  at  a 
speed  of  16  knots,  resulting  in  a  roll  reduction  of  68%.  More 
results  from  HMS  Carlskrona  are  given  in  [12]  and  [13], 


Without  ROLL-NIX 


Figure  4.  Results  from  sea  trials  with  the  minelayer  HMS 
Carlskrona  (L  =  105  m)  at  a  speed  of  16  knots  and  in 
beam  seas  (4  Beaufort) .  The  significant  roll  angle 
was  reduced  by  68%  with  ROLL-NIX  (see  (5.1)). 


5.3  Attack  Craft 

Measurements  with  and  without  ROLL-NIX  roll  damping  have 
been  carried  out  with  an  attack  craft  (L  =  35  m)  of  the  Royal 
Swedish  Navy.  Normally,  a  roll  reduction  in  the  order  of  45-55% 
was  achieved  with  ROLL-NIX,  but  at  27  knots  and  in  stern 
quartering  seas  (4  Beaufort)  the  reduction  was  58%.  Figure  5 
shows  this  result.  The  roll  and  heading  angles  were  recorded 
during  the  trial,  which  was  carried  out  with  manual  control  of 
the  heading.  The  helmsman  stated  that  it  was  easier  to  keep  the 
ship's  course  when  ROLL-NIX  was  active.  This  is  clearly  shown  in 
Figure  5,  where  the  course  deviations  from  the  experiment  are 
smaller  with  ROLL-NIX  than  without. 

More  results  from  the  attack  craft  trials  are  given  in  [12] 
and  [13]. 


Table  2.  Summary  of  measured  roll  reductions  with  ROLL-NIX  (see 
(5.1))  for  different  ship  types. 


— 

Length 

[m] 

Ship 

speed 

[knots] 

Maximum 

rudder 

rate 

[deg/s] 

Maximum 
roll  reduction 
with  ROLL-NIX 

Average 
roll  reduction 
with  ROLL-NIX 

Minelayer 

105 

13-17 

8 

68% 

40  -  50% 

Attack 

Craft 

35 

27 

8 

58% 

45  -  55% 

Passenger 

Ship 

120 

_ 

19 

_ 1 

9 

56% 

45  -  50% 

5.4  Passenger  Ship 

A  series  of  trials  with  a  passenger  ship  (L  =  120  m)  were 
also  carried  out.  At  a  ship's  speed  of  about  19  knots  and  in 
different  wave  conditions  ROLL-NIX  reduced  the  roll  in  average 
with  45-50%.  One  result  is  shown  in  Figure  6,  where  the  roll 
reduction  with  ROLL-NIX  is  56%. 
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Figure  5.  Results  from  sea  trials  with  an  attack  craft  (L  =  35 
m)  at  a  speed  of  27  knots  and  in  stern  quartering  seas 
(4  Beaufort) .  The  significant  roll  angle  was  reduced 
by  58%  with  ROLL-NIX  (see  (5.1)). 


mthout  ROLL 


With  ROLL -NIX 


Figure  6.  Results  from  sea  trials  with  a  passenger  ship  (L  =  120 
m)  at  a  speed  of  19  knots  and  in  beam  seas.  The 
significant  roll  angle  was  reduced  by  56%  with  ROLL- 
NIX  (see  (5.1)). 


The  measured  roll  reductions  with  ROLL-NIX  are  summarized  in 
Table  2.  The  average  roll  reduction  for  the  three  ship  types 
(minelayer  L  =  105  m,  attack  craft  L  =  35  m  and  passenger  ship  L 
=  120  m)  is  in  the  order  of  40-50%  and  the  maximum  roll  reduction 
in  special  sea  conditions  between  56%  and  68%.  These  roll 
reductions  are  very  close  to  the  reductions  that  would  be 
expected  from  an  active  fin  stabilizing  system.  Computer 


simulations  carried  out  sbow  that,  if  the  requirements  on  roll 
damping  are  extremely  high,  ROLL-NIX  and  active  fins  should  be 
used  at  the  same  time. 

6.  OPERATIONAL  EXPERIENCES 

The  compiled  experience  of  ROLL-NIX  in  operation  is  summed 
to  more  than  eight  years  (April  1990) .  Problems  with  the  ROLL- 
NIX  equipment  are  extremely  unusual,  since  the  system's  hardware 
components  are  very  reliable. 

The  control  pane^  (see  Figure  1)  is  designed  with  a  very 
convenient  man-machine  interface.  The  operators  are  in  almost 
all  cases  very  pleased  with  the  appearance  and  functional  layout 
of  the  control  panel. 

In  order  to  get  an  estimate  of  the  percentage  use  of  ROLL- 
NIX  on  a  typical  naval  ship,  the  time  in  use  was  measured  on  HMS 
Carlskrona  by  the  ship's  officers  during  the  winter  training 
cruise,  1987-88.  The  time  of  use  is  shown  in  Table  3.  Notice 
that  there  are  four  different,  possible  combinations: 

-  ROLL-NIX  :  Roll  Damping  +  Autopilot 

-  ROLL-NIX  :  Roll  Damping  +  Manual  Steering 

-  ROLL-NIX  :  Autopilot  only 

-  Manual  Steering  (no  ROLL-NIX) 


Table  3.  Time  of  use  of  ROLL-NIX  recorded  by  the  officers  in 
command  on  HMS  Carlskrona  on  the  winter  training  cruise 
1987  -  88. 


ROLL-NIX 

Manual 
Steering 
(no  ROLL-NIX) 

Roll  Damping 
+ 

Autopilot 

Roll  Damping 
+ 

Manual  Steering 

Autopilot 

only 

29% 

39% 

14% 

18% 

82% 

18% 
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Thus,  ROLL-NIX  was  used  82%  of  the  voyage  time. 


Commander  Hallin,  Captain  of  HMS  Carlskrona  during  the 
winter  training  cruise  1987-88,  has  told  about  an  interesting  and 
significant  occasion: 

"This  particular  occasion  was  when  the  ship  was  off  the 
Dutch  coast,  bound  for  den  Helder,  with  seas  coming  in 
from  astern  on  the  port  quarter.  I  was  resting  in  my 
cabin.  The  time  was  04.00  hrs.  Suddenly,  I  sensed 
that  the  ship  had  started  to  roll  perceptibly,  and  I 
wondered  what  was  going  on.  At  once,  I  went  up  on  deck 
and  asked  the  officer  of  the  watch  what  on  earth  was 
happening,  and  what  the  reason  was  for  this  sudden 
increase  in  the  ship's  rolling  motion.  I  was  surprised 
to  receive  the  reply  'We  have  just  switched  off  the 
ROLL-NIX.  We  need  to  have  some  data  without  ROLL-NIX 
working,  to  see  how  much  damping  can  be  achieved! '  I 
think  that  that  is  the  most  illustrative  experience  I 
have  had  of  the  ROLL-NIX  system  to  date . " 

7 .  CONCLUSIONS 

Rudder-Roll  Stabilization  (RHS)  is  by  now  a  very  well  proven 
technique.  It  is  shown  in  the  paper  that  an  RRS  system  such  as 
ROLL-NIX  reduces  the  roll  motion  by  40-50%  in  average  and  up  to 
almost  70%  in  favorable  wave  conditions.  The  results  are 
verified  by  sea  trials  with  a  minelayer,  an  attack  craft  and  a 
passenger  vessel. 

The  ROLL-NIX  system  works  with  relatively  low  rudder  rates. 
The  maximum  rudder  rate  required  is  in  the  order  of  3-10  deg/r. 
This  means  that  standard  steering  gears  can  be  used,  possibly 
with  two  pumps  working  at  the  same  time. 

When  designing  a  rudder  control  system  it  is  important  to 
consider  all  the  different  tasks:  course-keeping,  turning  and 
roll  damping.  Since  the  steering  gear  and  rudder  system  is  the 
only  actuator  used  for  all  tasks,  it  is  important  in  the  design 
to  Integrate  the  control  system  as  much  as  possible  in  order  to 
obtain  a  good  overall  behavior.  These  considerations  have  been 
made  in  the  ROLL-NIX  system.  In  the  future  it  seems  to  be  very 
likely  that  almost  all  rudder  control  systems  will  contain  at 
least  these  three  tasks:  course-keeping,  turning  and  roll 
damping. 
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AUTOMATIC  SHIP  STEERING  FOR  SURVEY  APPLICATIONS 


by  Jules  Kriegsman 
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1 .  ABSTRACT 

A  real-time,  computer-controlled,  track-keeping  system  has 
been  developed  that  very  accurately  steers  a  survey  ship  along  a 
prescribed  rhumb  line  track.  Prior  to  this  development,  less  accu¬ 
rate  track  control  was  achieved  via  conventional  autopilot  steering 
of  a  constant  ship  heading,  in  conjunction  with  manual  conning 
corrections  to  compensate  for  track  errors  arising  from  environmen¬ 
tal  factors.  The  system  consists  of  an  Integrated  Navigation  Sys¬ 
tem,  a  track-keeping  interface,  and  the  ship’s  autopilot.  The 
navigation  system  computer  integrates  position  data  from  continuous 
fix  radio  and  satellite  positioning  systems,  inertial  navigation 
systems,  and  dead  reckon  aids  to  develop  Best  Present  Position 
(BPP) .  The  navigation  computer  receives  a  manual  input  of  the 
prescribed  rhumb  line  track  specified  by  a  position  and  heading 
angle,  also  commonly  referred  to  as  the  Desired  Ground  Track  (DGT) . 
At  prescribed  equally  spaced  times,  BPP  is  used  to  compute  the 
distance  that  the  ship  is  off  track.  The  off-track  distance  is 
used  to  develop  proportional  and  integral  heading  corrections, 
which  are  fed  via  the  track-keeping  interface  to  the  autopilot. 

The  autopilot  accepts  the  correction  signal  as  a  bias  to  the  DGT 
heading,  resulting  in  the  ship  being  steered  toward  the  desired 
track. 

2 .  INTRODUCTION 

Survey  ships  that  collect  bathymetric,  gravimetric,  and  magne¬ 
tic  data  efficiently  accomplish  the  data  gathering  objective  by 
collecting  the  data  along  prescribed  rhumb  line  tracks.  This  paper 
describes  an  operational  computer-based  track-keeping  algorithm, 
installed  aboard  various  survey  ships,  that  computes  heading  cor¬ 
rections  based  on  the  ship's  distance  off  track.  A  portion  of  the 
heading  correction  is  transmitted  to  the  ship's  autopilot  and  ap¬ 
portioned  over  a  number  of  increments  between  computations  in  order 
to  gradually  lock  the  ship  onto  the  track.  The  track-keeping  algo¬ 
rithm,  described  herein,  requires  high-quality  BPP  data,  such  as 
provided  by  continuous  Satellite  or  Loran  navigation  aids.  The 
control  law  is  composed  of  Proportional  and  Integral  components  (PI 
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controller) ,  which  are  computed  using  the  ship's  off-track  distance 
(DCT) .  Generally,  the  proportional  component  compensates  for 
short-duration  disturbances  such  as  wind  gusts,  whereas  the  integ¬ 
ral  component  compensates  for  persistent  disturbances  such  as  ocean 
currents.  Closing  velocity  limitations  were  imposed  to  provide  an 
alternative  approach  to  conventional  differential  control. 

3 .  FUNCTIONAL  DESCRIPTION 

Prior  to  commencement  of  the  survey  data  acquisition  process, 
the  desired  ground  track  (DGT)  heading  is  set  into  the  autopilot, 
and  the  helmsman  steers  the  ship  to  the  desired  track,  to  within 
start-up  tolerances,  to  initiate  the  ship's  automatic  track-keeping 
operations.  The  automatic  track-keeping  system  provides  the  neces¬ 
sary  corrections  to  steer  the  ship  onto  the  desired  track.  Envi¬ 
ronmental  disturbances  such  as  wind,  waves,  and  ocean  currents, 
tend  to  drive  the  ship  off  track,  and  it  is  the  function  of  the 
automatic  track-keeping  system  to  restore  the  ship  to  the  desired 
track.  The  open  switch  position  shown  on  the  functional  block 
diagram  in  Figure  1  indicates  the  ship  steering  control  loop  prior 
to  the  start  of  the  survey  line  (open-loop  operation) .  When  the 
ship  reaches  the  start-up  tolerance  of  the  track,  automatic  track 
control  is  activated  by  closing  the  switch,  which  adds  the  track¬ 
keeping  control  law  to  the  steering  control  mechanization  (closed- 
loop  operation) . 

4.  CONTROL  LAW  IMPLEMENTATION 

The  track-keeping  eguations  shown  in  Figure  2  add  proportional 
and  integral  heading  compensation  (PI  control  law)  to  the  auto¬ 
pilot,  as  required.  Switches  1  and  2,  shown  in  Figure  2,  provide  a 
means  of  indicating  the  application  status  of  the  compensation 
described  herein.  A  survey  line  is  started  when  the  ship  is  typi¬ 
cally  within  0.1  nautical  miles  of  the  track.  To  prevent  excessive 
integral  compensation  accumulation,  resulting  in  undesirable  over¬ 
shoot  of  the  track,  only  proportional  compensation  is  applied 
(switch  1  is  closed  and  switch  2  is  open)  until  the  ship  is  within 
0.1  nautical  mile  of  the  track,  at  which  time  integral  compensation 
is  added  (switch  2  is  closed).  To  further  minimize  the  possibility 
of  overshoot  and  ensure  a  smooth  lock  onto  the  track,  no  propor¬ 
tional  or  additional  Integral  compensation  is  added  to  the  auto¬ 
pilot  when  the  ship's  closing  velocity  exceeds  0.5  ]aiot  (i.e., 
switch  1  is  opened  when  the  component  of  the  ship's  velocity  per¬ 
pendicular  to  and  moving  toward  the  track  exceeds  0.5  knot). 

5.  CONTROL  LAW  GAIN  SELECTION 

The  proportional  and  Integral  gain  constants  IC  and  K, ,  re¬ 
spectively,  were  selected  to  yield  a  maximum  permissible  propor¬ 
tional  heading  correction  of  15  degrees  for  a  ship's  off-track 
distance  of  0.1  nautical  mile  from  the  track  and  an  integral  time 
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(reset  rate)  corresponding  to  a  ship's  nominal  velocity  of  15 

knots.  Using  these  notions,  the  gain  development  shown  in  Figure  3 
indicates  design  values  of  3  minutes  for  and  gain  values  of 

150  degrees  per  nautical  mile  and  3000  degrees  per  nautical  mile 
per  hour  for  K  and  Kj ,  respectively.  Using  a  reduced-order  model 
of  ship  dynamics  consisting  of  yaw  and  sway,  rudder  dynamics,  and 
autopilot  controller  dynamics,  application  of  Liapunov  stability 
analysis  techniques  verified  that  the  selected  design  constants 
yield  a  stable  system. 

6.  PERFORMANCE  SIMULATION 

A  ship  motion  simulation  computer  program  featuring  linear- 
state  space  models  of  the  ship's  sway,  yaw,  and  roll  motions;  a 
non-linear  surge  equation  to  account  for  rudder,  sway,  and  coupled 
yaw/sway  drag;  and  autopilot  and  steering  hydraulics  models,  was 
employed.  Track-keeping  algorithm  performance  was  evaluated 
through  simulations  of  the  ship's  response  to  various  external 
factors  driving  the  ship  off  track.  The  simulation  assumed  a  ship 
velocity  of  20  knots,  a  3-knot  ocean  current  crossing  the  track  at 
45  degrees,  and  a  0.5-nautical  mile  initial  ship  offset  from  the 
track.  The  maximum  heading  correction  permitted  was  25  degrees  for 
0.33  nautical  mile,  or  greater,  distance  off  track  and  15  degrees, 
otherwise.  The  maximum  incremental  heading  correction  permitted 
was  2  degrees.  Integral  compensation  updates  were  introduced  only 
when  the  ship's  distance  cross  track  was  0.1  nautical  mile  or  less. 

The  autopilot  heading  correction,  the  ship's  distance  cross 
track,  and  PI  control  law  graphs,  depicted  in  Figures  4,  5,  and  6, 
respectively,  were  generated  from  the  simulation.  The  negative  and 
positive  constant  slope  portions  in  Figure  4  reflect  time  frames  in 
which  the  theoretical  PI  control  law  correction  exceeded  the  maxi¬ 
mum  2  degrees  per  Increment  applied  correction  limitation.  In 
Figure  4,  the  size  of  an  increment  is  indicated  by  the  vertical 
distance  between  successive  plot  symbols.  The  left  and  right  flat 
portions  of  the  graph,  respectively,  indicate  a  25-degree  maximum 
heading  correction  for  the  ship's  off-track  distance  of  0.33  nauti¬ 
cal  mile,  or  more,  and  a  15-degree  maximum  heading  correction, 
otherwise.  Finally,  the  curved  portion  in  Figure  4  indicates  in¬ 
stances  where  less  than  maximum  allowable  incremental  heading  cor¬ 
rections  were  required. 

Figure  5  reflects  the  ship's  off-track  distance  in  response  to 
the  combination  of  the  applied  heading  corrections  indicated  in 
Figure  4,  the  ocean-current  environment,  the  ship's  initial  offset 
from  the  track,  and  the  ship's  velocity.  Due  to  the  2  degree  per 
increment  heading  correction  application  limitation,  the  effect  of 
the  ocean  current  causes  the  ship  to  initially  move  farther  away 
from  the  track,  as  indicated  at  the  start  of  the  run.  As  the  head¬ 
ing  correction  application  increased  to  the  25-degree  limit  permit¬ 
ted  for  offsets  of  0.33  nautical  mile,  or  more,  the  off-track  dis- 
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Figure  3.  Proportional  and  integral  gain  selection. 
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tance  decreases  rapidly.  When  the  off-track  distance  falls  below 
0.33  nautical  mile,  the  maximum  heading  correction  application  is 
reduced  to  15  degrees,  resulting  in  a  corresponding  decreased  rate 
of  ship  movement  toward  the  track.  Finally,  as  the  off-track  dis¬ 
tance  falls  below  0.1  nautical  mile,  the  proportional  heading  cor¬ 
rection  gradually  diminishes,  while  the  integral  compensation  com¬ 
mences.  Integral  compensation  builds  up  to  the  heading  correction 
value  required  to  compensate  for  the  steady-state  ocean  current  at 
the  point  of  reaching  zero  off-track  distance. 

Figure  6  demonstrates  the  proportional  and  integral  correc¬ 
tions  generated  by  the  PI  control  law.  The  proportional  correction 
graph  is  identical  in  shape  to  the  ship's  off-track  distance  graph 
shown  in  Figure  5.  In  accordance  with  the  correction  application 
criteria  discussed  above,  the  integral  compensation  graph  indicates 
zero  values  for  the  ship's  off-track  distances  in  excess  of  0.1 
nautical  mile,  and  gradual  accumulation  to  the  value  required  to 
compensate  for  the  ocean  current,  in  the  0.1-nautical  mile  off¬ 
track  distance  range. 

7 .  TRACK-KEEPING  IMPLEMENTATION 

The  automatic  track-keeping  system  was  implemented  on  several 
survey  ships  with  varying  host  computers  and  ship  configurations  as 
shown  in  Figure  7.  The  PI  controller  algorithm  was  hosted  in  the 
existing  navigation  computer,  and  an  electrical  interface  was  de¬ 
veloped  to  handle  data  communications  between  the  navigation  com¬ 
puter  and  the  ship's  autopilot  equipment.  The  track-keeping  inter¬ 
face  included  digital-to-analog  conversion  functions  and  provided 
options  for  communications  with  two  different  types  of  host  comput¬ 
ers;  namely,  the  AN/UYK-20  Navy  Standard  minicomputer  and  the  HP- 
lOOOE  commercial  minicomputer.  Figures  8  and  9,  respectively,  show 
the  configuration  of  the  track-keeping  interface  designed  for  the 
two  types  of  host  computers.  Autopilot  configuration  modifications 
entailed  incorporation  of  circuitry  to  add  PI  controller-derived 
heading  corrections  to  the  selected  DGT  heading.  This  permitted 
the  autopilot  system  to  function  normally  in  all  other  respects  so 
as  to  seek  and  lock  onto  a  selected  DGT.  In  this  case,  however,  PI 
controller  corrections  cause  the  autopilot  system  to  steer  a  rhumb 
line  survey  track. 

Finally,  sea  tests  were  conducted  to  fine-tune  design  con¬ 
stants  for  each  ship's  implementation.  The  robustness  of  the  de¬ 
sign  was  evidenced  by  the  fact  that  successful  implementation  was 
achieved  with  only  minimal  parameter  tuning  for  ships  with  widely 
divergent  characteristics. 

8.  CONCLUSION 

Proportional  and  integral  heading  corrections  derived  from  a 
ship's  distance  off  track  can  be  applied  to  the  autopilot  of  a 
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Figure  7.  Track-keeping  system  integration. 
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figure  8.  Track-keeping  interface,  functional  block  diagram, 
AN/UYK-20  configuration. 
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HP-1000  configuration. 


survey  ship  to  lock  onto  and  precisely  steer  the  ship  along  a  pre¬ 
scribed  rhumb  line  track,  provided  accurate  continuous  navigation 
data  is  available. 


3.310 


H„  MARINE  AUTOPILOT  DESIGN  FOR 
COURSE-KEEPING  AND  COURSE-CHANGING 


By 

NA.  Fairbairn  and  MJ.  Grimble 


Industrial  Control  Unit 
University  of  Strathclyde 
Marland  House 
50  George  Stre^ 
Glasgow.  Gl  IQE 


Abstract 

Over  the  last  eight  years  the  new  Ho.  robust  design  techniques  have  been  develop^  and 
are  now  finding  application  in  industry.  They  enable  systems  to  be  designed  with  relatively 
low  order  models  and  the  subsequent  feedback  system  is  robust  in  the  face  of  variations  in  the 
system  parameters.  In  marine  system  ship  models  are  often  poorly  defined  since  it  is  usually 
too  expensive  to  obtain  tank  test  results  or  identification  data. 

The  method  can  be  extended  to  the  design  of  toll  stabilization,  ship  positioning  systems 
and  steering  systems. 

The  objective  of  this  paper  will  be  to  introduce  the  new  approach  and  to  detail  the 
advantages  of  the  robust  design  procedure.  An  autopilot  design  study  will  then  be  presented 
to  illustrate  the  various  stages  of  the  design  procedure  and  the  performance  which  can  be 
achieved. 

Simulation  is  carried  out  using  a  single-input  single-output  ship  model  with  non-linear 
steering  gear  with  a  autopilot  It  is  shown  that  the  approach  is  a  good  feedback 
desi^  tool  for  both  the  course-changing  and  course-keeping  modes  of  the  ship 
steering  operation.  In  addition,  the  fixed  controller  gives  good  robusmess  to 
parameter  variations. 

Introduction 

The  Hoo  design  approu  duceo  by  Zames  (1981)  provides  a  mathematical  framework 
which  is  particularly  appropnate  tor  robustness  studies  and  feedback  controller  design  for 
uncertain  systems.  It  is  often  the  case  that  the  likely  modelling  error  can  be  pre-determined 
and  the  question  then  arises  how  best  to  design  an  optimal  controller.  An  Ho,  design 
provides  such  a  solution. 
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For  marine  applications,  robustness  to  wind  and  wave  disturbances  must  be  achieved  and 
these  phenomena  are  presented  by  reasonably  well-defined  power  spectra.  Optimal  rejection 
of  these  disturbances  can  be  achieved  by  shaping  the  frequency  response  of  the  closed-loop 
transfer  function. 

Ship  models  are  usually  poorly  defined  since  it  is  rare  for  exhaustive  tests  to  be 
performed  on  scale  models  or  on  the  actual  vessels.  A  tolerance  to  the  unmodelled  dynamics  is 
therefore  required  and  this  is  provided  by  the  Hoo  design  procedure.  Although  this 
approach  may  not  be  the  most  appropriate  for  many  applications,  it  does  appear  that  the 
stochastic  nature  of  marine  systems  and  the  poor  models  normaUy  available  make  them 
particularly  suitable  for  this  type  of  problem.  In  this  paper  the  ship  steering  problem  is 
considered. 

The  ship  steering  control  problem  has  received  much  attention  over  the  years  using 
several  different  control  philosophies.  Many  autopilots  which  are  based  on  modem  control 
theory  are  adaptive  -  for  example  van  Amerongen  (1980)  which  uses  the  MRAS  (Model 
Reference  Adaptive  System)  approach  of  Landau  (1979).  Kallstrom  et  al  (1979),  Mort  and 

Linkens  (1981)  use  the  STR  (self-tuning  regulator)  approach  of  Astrom  (1980).  Another 
adaptive  autopilot  is  that  by  Rios-Neto  and  da  Cruz  (1985). 

The  Hoo  fixed  controller  yields  a  feedback  controller  which  is  robust  with  respect  to 
parameter  variations.  The  purpose  of  this  paper  is  to  investigate  the  performance  of  a  Hxed 
Hoo  controller  in  the  presence  of  nonlinearity  from  the  rudder  and  parameter  variations  in 
the  ship  due  to  speed  changes. 

Both  course-changing  and  course-keeping  modes  of  operation  are  considered. 

In  course-changing,  the  ship  is  r^uired  to  follow  a  step  change  in  desired  heading  with  no 
overshoot  or  st^y-state  errors  in  spite  of  environmental  disturbances  such  as  wind  and  sea. 

In  course-keeping  mode,  the  controller  is  requited  not  to  actuate  the  rudd^  against  the  wave 
motion  to  achieve  fuel  economy  and  reduced  rudder  wear. 

The  course-keeping  model  of  operation  is  achieved  either  by  including  the  wave  model  as 
an  output  disturbance  model  and  penalizing  a  particular  term  in  the  cost  function  or  by 
frequency-dependent  weightings  in  the  peiformance  index. 

The  papn  is  organized  as  follows:  description  of  the  modelling  of  the  ship,  rudder  and 
disturbances  in  §2;  derivation  of  the  linear  ship  models  and  wave  models  for  a  number  of 
different  sea  states  in  §3;  description  of  the  controller  design  and  simulations  for 
course-keeping  and  course-changing  in  §4  and  §S  respectively. 

1.1  Ship  coordinate  system 

Fig.  1  shows  the  ship  coordinate  systems.  The  ship  is  depicted  as  a  rectangular  block. 

The  origin  is  at  the  geometric  centre  of  the  ship.  The  ship  velocity  U  has  components  u  and  v 
in  the  x  and  y  directions  respectively.  Steering  motion  ties  place  around  the  z-axis  which  is 
vertically  through  the  origin. 
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2.  Marine  System  Model 


Fig.  2  shows  the  linear  discrete-dme  model  used  for  the  ship  autopilot  design.  The  ship 
is  represented  as  A'^B  where  B  =  B|^z'^  and  k  is  a  delay  tenn.  It  is  assumed  at  all  times  in 
this  application  that  k=l.  The  yaw  angle  <p  =  y  is  assuined  to  be  identical  to  the  ship  heading 
and  u  is  the  control  signal  (demanded  rudder  angle).  Wind  is  modelled  as  an  iwut 
disturbance  A'^Cj  and  wave  motion  is  m^ell^  as  an  output  disturbance  A„  C„.  The 
controller  (autopilot)  is  represented  by  QiCf..  The  yaw  angle  ip  must  follow  a  ^manded 
heading  =  r(t). 

3.  Ship  and  Rudder  Modelling 

3.1  Ship  modelling 


In  this  section,  the  modelling  of  the  ship  is  considered.  The  ship  is  considered  to  be 
linear  and  time-invariant.  The  only  factor  which  is  assumed  to  affect  the  model  is  the  speed 
U  of  the  ship.  Robustness  with  respect  to  speed  variation  is  considered  in  detail  in  a  later 
section. 


In  order  to  generate  linear  model  of  the  ship,  a  standard  procedure  is  followed  which  may 
be  found  for  example  in  Zuidweg  (1970).  The  following  well-known  transfer  function  model 
may  be  derived: 


^  __K _ 

Ms)  ~  s(l  +st) 


(1) 


This  transfer  function  represents  the  response  of  the  heading  angle  \|/  to  small  changes  in 
rudder  angle  y  and  was  originally  proposed  by  Nomoto  (1957).  Its  simplicity  renders  it 
attractive  for  feedback  controller  design  purposes. 

3. 1.1.1  Speed  variation 

The  model  parameters  t,  k  vary  with  the  forward  speed  of  the  ship,  U.  If  x  j  and  ki 
represent  the  ship  parameter  at  speed  Uj  then,atasp«^ofU2,K2  =  KjU2AJj  and 

X2  =  TiU  j  AJ2-  This  is  obtained  from  ^Istrom  (1979).  Clearly,  the  gain  K  is  directly 

propomonal  to  the  ship  speed  while  the  time  constant  x  is  inversely  prcqxirtionaL  The 
combination  of  both  these  variations  with  speed  suggests  a  ratter  non-linear  characteristic 
oyer  the  operating  speed  range  of  the  ship.  It  is  hoped  that  the  fixed  controller  will 
give  good  performance  robustness  over  a  range  of  speeds. 

3.2  Rudder  dynamics 

In  theory,  it  would  be  possible  to  simulate  the  ship  with  a  linear  feedback  control  law 
assuming  that  there  were  no  limitations  on  rudder  movement  in  terms  of  position  and  velocity. 
In  practice,  however,  the  constraints  on  the  rudder  movement  are  such  that  they  must  be 
included  in  the  simulation  study.  This  has  been  considered  extensively  in  the  marine 
literature.  A  model  of  the  rudder  could  be  as  follows: 
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if  u-5  >  0 

on* 

II 

O 

if  u-8  =  0 

(2) 

if  u-8  <0 

The  parameter  |i  is  adjusted  to  give  a  rudder  model  response  close  to  that  of  the  real 
rudder.  Fig.  3.  shows  the  rudder  rate  as  a  function  of  the  position  error.  The  value  of  the 
parameter  n  will  depend  on  the  moment  of  inertia  of  the  rutkler.  Typical  values  will  be 
in  the  range  3  £  p.  ^  10.  This  model  was  taken  from  Uos-Neto  and  Cruz  (1985). 

4.  Disturbances 

Environmental  disturbances  which  any  affect  a  ship  at  sea  include  wave  motion,  current  and 
wind.  High  frequency  wave  motion  is  considered  to  be  the  most  inqxrrtant  disturbance ; 
current  and  wind  may  be  considered  to  be  low  frequency  disturbances  which  can  be  rejected 
by  a  control  system  relatively  easily  by  the  introduction  of  integral  action  Qow  frequency  gain). 

In  some  c^s,  it  is  necessary  to  actuate  the  rudder  to  counter  disturbances  due  to  the  sea 
in  order  to  achieve  high  accuracy  in  heading.  This  high  accuracy  is  achieved,  however,  only 
at  the  expense  of  a  very  lively  rudder  action.  This  can  obviously  lead  to  deterioration  of  the 
rudder  and  steering  gear  and  in  addition  a  higher  fuel  cost  will  be  incurred.  It  is  important 
therefore  to  have  two  different  autopilot  strategies 

(i)  For  high  accuracy  of  heading  and  ftw  good  manoeuvring  ability  (course-changing) 

(ii)  For  reasonable  accuracy  of  heading  in  steady-state  but  with  a  less  lively  rudder  action 
(course-keeping). 

Under  strategy  (i),  the  feedback  controller  rejects  disturbances  due  to  wave  nxrtion,  that 
IS  introduMS  high  gain  where  the  wave  spectrum  may  be  dominant.  Under  strategy  (ii), 
however,  it  is  important  that  the  controller  introduces  low  gain  where  the  wave  spectrum  is 
dominant. 

4.1  Wind  Modelling 

Wind  has  low  frequency  disturbance  compcxients  which  must  be  rejected  by  the 
control  system-  for  example  if  a  gust  of  wind  causes  a  heading  error  then  it  is  necessary  for 
the  rudder  to  actuate  in  an  appropriate  manner  so  that  the  heading  error  is  cortected.  The 
wind  may  be  considered  to  be  a  d.c.  disturbance  for  present  discussions. 

T^e  magnitude  spectrum  of  the  wind  disturbance  model  is  therefore  dominant  at  d.c.  and 
low  frequencies  while  having  a  low  value  at  high  frequencies.  In  order  to  achieve  this  type  of 
spectrum,  the  wind  is  modelled  by  an  integrator  as  follows: 


Clearly  Wd(r  =  1)  =  «  and  W^jCz  =  -1)  =  0.015.  Fig.  4  shows  a  magnitude  bode  diagram  for 
the  wind  m^l. 


4.2  Wave  Modelling 

Modelling  of  the  sea  has  received  much  attention  in  the  marine  litentuie.  Wave  amplitude 
spectra  such  as  the  Pierson-Moscowitz  spectrum  OPierson  and  Moscowitz  (1964))  and  die  ITTC 
spectrum  which  was  introduced  at  the  12th  Intenuttional  Towing  Tank  Conference  (see  for 
example  Beukelman  and  Huijser  (1976))  are  well  established.  These  spectra  represent  the 
frequency  characteristics  of  the  sea  for  different  significant  wave  heights. 

Modelling  of  the  effects  of  the  sea  mi  a  ship  in  terms  of  angular  disturba^  is  lUher 
mote  ^fficulL  The  ship  is  modelled  as  a  rectangulv  block  in  order  tlw  relatively  simple 
expressions  may  be  derived  for  the  fences  on  the  ship  in  the  x  and  y  directions  and  fa  the 
torque  about  the  z-axis.  In  the  study  of  the  autopilot,  the  forces  in  tte  x  and  y  directions 
are  neglected  since  only  totque  about  that  z-axis  is  relevant  to  steering. 

Fig.  5  shows  the  block-shaped  ship  travelling  at  an  angle  p  with  respect  to  the  fixed  q  and 
r  axes  (see  Blanke  (1981)).  The  encounter  angle  X  =  H  -  V- 


4.2.4  Waves  as  an  output  disturbance 

In  order  that  the  wave  disturbance  may  be  included  in  the  standard  stochastic  system 
description  described  in  §2,  it  is  necessary  to  model  the  wave  disturbance  as  an  ou^ut 
disturbance.  In  this  way,  it  is  possible  to  distinguish  between  the  wind  and  wave 
disturbances  in  die  H,,  cost  fiction. 

A  second  order  transfer  function  is  used  to  model  the  waves  as  follows  (see  Jin  and 
Grimble  (1986)  and  many  others). 


W 


w 


X(3)s 

s^  +  X(2)  s  +  X^(l) 


(4) 


The  time  series  of  angular  accelerations  on  the  ship  due  to  waves  is  produced  by  driving 
with  a  Gaussian  white  noise  sequence. 

In  order  to  confute  the  coefficients  of  the  transfer  function  W^,  a  FFT  is  carried  out  on 
the  time  series  of  K^ues.  This  produces  the  angular  acceleration  spectrum.  The  coefficients 
X(l),  X(2),  X(3)  are  then  cooqiuted  using  a  standard  least  squares  fitting  program. 

5.  Ship  and  disturbance  models 

In  this  section,  a  ship  model  is  introduced  which  will  be  used  for  simulation  testing  of  the 
Ho,  autqiilot.  In  fact  dme  models  will  be  derived;  (i)  Representing  the  ship  at  low  spoM, 

(6  knots),  (ii)  Representin|  the  ship  at  high  speed  (16  knra),  (iii)  Representing  the  snip  at 
an  intermediate  speed  =  (11  knots).  6  to  16  knots  (=  3  to  8  m/s)  is  considered  to  be  the  speed 
range  of  the  ship. 
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Three  linear  models  were  derived  each  representing  different  sea  conditions.  These 
models  will  be  used  when  evaluating  the  course-keeping  performance  of  the  Hge  autq)ilot 
(i)  Low  sea  conditions  -  Che  calmest  sea  which  is  modelled  is  Sea  State  3  at  a  wave  encounter 
angle  of  x  =  4S°,  (ii)  high  sea  conditions  -  the  worst  possible  sea  condition  is  considered  to 
be  Sea-State  8  at  a  wave  encounter  angle  of  x  =  45°.  This  is  an  extremely  rough  sea.  (iii) 
intramediate  sea  conditions  -  sea  state  5  with  an  encounter  angle  of  x  =  4S°. 

5.2  ShipModtlParameUn 

The  three  gains  and  time  constant  at  three  different  speeds  are  summarized  in  Table  1  and 
the  discrete-time  model  parameters  ate  in  Table  2.  The  ri^uency  responses  of  the  three  ship 
models  ate  in  Fig.  ti. 

5.2  Wave  Model  parameters 

Table  3  summarizes  the  three  wave  model  parameter  X(l),  X(2),  X(3)  in  equatimi  (24)  for 
Model  2  of  the  ship  considered  at  three  different  sea  conditions.  These  parameters  were 
obtained  using  a  s^trum  fitting  program  and  the  angular  acceleration  times-series. 

Table  4  lists  the  discrete-time  wave  model  parameters.  Fig.  7  shows  the  magnitude 
frequency  responses  for  these  three  linear  models. 

6.  Hg,  Course  Changing  Autopilot 

In  this  section,  an  Heo  controller  is  designed  in  order  to  yield  good  course-changing 
control  action  •  that  is  in  order  that  the  ship  follows  a  step  change  in  desired  heading  quickly 
and  with  no  overshoot.  The  wave  disturbance  term  may  be  omitted  from  the  cost  function  in 
this  case.  High  gain  may  be  introduced  at  the  high  frequency  part  of  the  disturbance 
spectrum  if  required  by  simply  costing  the  tracking  error  sign^.  For  this  reason  and  for 
clarity  of  results,  wave  disturbance  is  neglected  in  the  simulations  in  this  section.  Wave 
effects  may  be  omitted  since  fuel  economy  is  not  the  main  criterion  when  manoeuvring. 

6.1  Ship  frequency  responses 

Fig.  4  shows  a  family  of  frequency  responses  of  the  ship.  The  ship  is  modelled  as  a  first 
ortter  lag  with  an  integrator  which  gives  a  d.c.  gain  of  <»>  and  d.c.  phase  lag  of  90  The 

gain  rolls  off  at  20  dB/decade.  The  extra  phase  lag  introduced  by  the  integrator  means  that 
the  phase  becomes  - 180  ®  at  high  frequency. 

6.2  Wind  frequency  responses 

Fig.  3  shows  the  wind  magnitude  frequency  responses.  It  has  a  similar  response  at  low 
frequency  to  the  ship  but  tolls  off  more  rapidly  at  high  frequency.  This  clearly  shows  the 
dominance  of  wind  at  low  frequencies. 

It  Avill  be  nc«ss^  to  introduce  high  gain  at  low  frequency  to  reject  wind  disturbances. 
This  high  d.c.  gain  is  introduced  automatically  if  the  wind  model  is  included.  An  alternative 
method  would  be  to  omit  the  wind  model  from  the  equations  and  introduce  integral  action  by 
means  of  the  error  weighting  function  in  the  cost  index. 
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6.3  Generalized  controller  design 


In  this  section,  a  generalized  H„o  controller  is  obtained  for  course-changing  (see  Gritnble 
1987)  and  Fairbaim  (1989)  for  details  of  the  generalized  Hoc  controller  calculation). 

The  performance  index  (cost  function)  which  is  minimized  is  as  follows; 

~=lzl=lV"’'^ 

where  is  the  spectral  density  of  the  signal: 

<p(t)  =  Pj-eft)  +  F(.u(t)  (6) 

The  criterion  minimized  is  a  weighted  sum  of  the  error  and  control  signals.  The  weighting 
transfer  functions  and  F^.  are  chosen  by  the  designer  to  trade  off  between  stability 
robustness  and  performance.  The  weighting  functions  are  expressed  in  polynomial  form  as 
follows: 


o  t-ii  c  cn 


(7) 


where  P^jj,  ^cn*  ^cd*  ^  ^+* 

The  GFL>  optimal  control  law  is  summarized  in  the  following  theorem. 
Theorem  I  (GH^  result) 


The  GH,m>  controller  to  minimize  the  criterion  (S)  may  be  coitqruted  by  finding  the 
minimum-degiee  solution  (F.GJfA)  where  F  e  P.,  G,  H  e  P ,  A,  e  R  with  respect  to  F  of  the 
following  coupled  polynomial  equations; 


FAPcdA.  +  L.G  =  Pp„CF* 

(8) 

FBFcdX  +  LH  =  F^.„CF* 

(9) 

whereLeP  is  as  follows 

^  “  *’cn*^cd®'^cn^cd'^ 

(10) 

and  factorize  L  as  follows: 

L  =  L+L. 

(11) 

where  L^.  e  P^.,  L.  c  P.. 
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The  GHoo  controller  follows  as: 


^f"C 
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fd 


GF, 


cd 


HP. 


cd 


(12) 


and  the  closed-loop  characteristic  polynomial  pj.  e  P+  is  given  by: 

Proof.  Grimble  (1987)  and  Fairbaim  (1989). 

Choosing  Pg  =  1  and  F^  =  0.1  the  generalized  Hoo  controller  is  coiiq>uted.  The 
coefficients  are  in  Table  6. 

6.4  Simulation 

Simulations  are  canied  out  by  solving  the  ship  differential  equation  with  the  non-linear 

rudder  model  included.  This  is  achieved  by  using  a  standard  Fortran  NAG  library  integration 
routine.  A  Fortran  77  simulation  program,  was  tteveloped  which  incorporated  the  NAG 
routine. 

Ideal  weather  conditions  are  assumed-  that  is  no  wind  or  waves.  The  wave  motion  is 
neglected  for  coune-chan^ng  as  mentioned  before.  Wind  disturbance  in  the  form  of  a  d.c. 
disturbance  is  considered  in  the  next  section. 

The  simulation  data  is  as  follows :  simulation  time  =  200  seconds,  rudder  angle  limit  = 
±35®  rudder  rate  (max)  =  5®/s. 

The  response  of  the  ship  to  a  desired  heading  of  60®  is  considered  for  an  initial 
condition  of  x|f  0, 5  -  0.  (In  addition  all  derivatives  of  ip,  S  are  zero).  The  GH,,  controller 
coefficients  are  in  Table  S.  The  open-loop  fr^uency  response  of  the  controlled  system  is  in 
Fig.  8.  It  is  clear  that  the  gain  and  phase  margins  are  excellent  Fig.  9  shows  the  time 
responses.  It  is  slow  due  to  the  inertia  of  the  rudder.  Care  must  be  taken  not  to  try  to  move 
the  rudder  too  fast  or  slew-rate  limiting  problems  will  be  experienced. 

6.5  Wind  disturbance 

In  this  section  the  wind  rejection  property  of  the  autopilot  is  ctmsidered.  Wind 
disturbance  will  be  considered  to  be  a  single  gust  which  causes  an  error  in  the  yaw  angle. 

The  ship  is  considered  to  integrate  the  effects  of  a  steady  wind.  That  is  a  steady  wind 
will  cause  a  constant  rate  of  turn.  In  simulation  this  is  achieved  by  simply  adt^g  a  ramp  to 
the  yaw  angle  i)r  for  a  short  period  of  time,  for  example  10  seconds.  This  simulates  the  effects 
of  a  maintained  gust  of  wind  for  120  seconds. 

The  demanded  heading  y  j  was  maintained  at  zero  and  the  disturbance  was  introduced  at 
T  =  100  seconds.  It  is  hop^  that  the  rudder  will  actuate  in  such  a  manner  as  to  return  the 
ship  to  the  correct  heading. 
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It  can  clearly  be  seen  from  Fig.  10  that  the  wind  disturbance  causes  an  error  in  heading. 
However,  the  high  gain  at  low  frequency,  introduced  by  the  inclusion  of  the  wind  disturbance 
model  in  the  cost  function,  reduces  the  error  to  zero,  llus  disturbance  rejection  result  will 
apply  to  other  low  frequency  effects  such  as  current  and  low  frequency  wave  motion. 

6.6  Robustness  with  respect  to  speed  variations 

In  this  section  the  robustness  of  the  frxed  controller  with  respect  to  model  variations  due 
to  speed  is  considered.  As  mentioned  in  §2,  the  ship  gain  increases  with  speed  while  the  time 
constant  decreases. 

The  Hg,  controller  calculated  in  the  previous  section  for  the  intermediate  speed  of  5.42 
m/s  was  tested  in  simulation  with  ship  models  representing  sptxds  of  3  m/s  and  8  m/s 
respectively,  the  corresponding  parameters  are  in  Table  1. 

Ship  speed  =  3m/s  (Fig.  1 1) 

With  a  lower  ship  speed  the  ship  gain  is  lower  and  the  time  constant  is  larger.  With  the 
same  controller,  it  is  expected  that  the  closed-loop  performance  of  the  ship  will  be  slower 
which  is  certainly  the  case  in  the  first  30  seconds. 

Ship  speed  =  8  m/s  (Fig.  12) 

With  a  higher  ship  speed  the  ship  gain  is  larger  and  the  open  loop  time  constant  is 
smaller. 

Fig.  12  for  the  generalized  Hoo  controller  indicares  that  the  response  is  alnoost  unchanged 
from  that  of  Fig.  9. 

7.  Hoo  Course-keeping  Controller 

In  this  section,  a  Hoo  controller  is  designed  which  will  maintain  the  heading  of  the  ship 
but  will  reduce  the  actuation  of  the  rudder  against  the  wave  motion  in  order  to  save  fuel  and 
to  minimize  rudder  wear. 

In  all  cases,  the  demanded  heading  is  assumed  to  be  zero  since  course-keeping  is  a 
steady  stare  problem. 

The  wave  motion  is  simulated  in  the  time  domain  by  nreans  of  equations  (4).  To  reduce  the 
number  of  simulation  traces,  only  the  extreme  cases  of  ^-States  3  and  8  will  be  considned. 

The  course-keeping  controller  is  designed  causing  no  wave  model  but  using  a  frequency- 
dependent  control  weighting. 

7. 1  Performance  of  course-changing  controller 

la  this  section,  the  performance  of  the  course-changing  controller  is  considered  when  the 
ship  is  affected  by  wave  motion. 
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It  is  clear  from  Figs.  13a ,  13  b  and  14a,  14  b  for  sea  states  3  and  8  respectively  that  the 
tracking  capability  of  die  course-changing  controller  is  excellent  This  is  achieved,  however, 
only  at  the  expense  of  a  veiy  active  n^lder.  For  Sea-state  3  the  heading  is  maintained  to  an 
accuracy  of  around  0.05°  while  the  rudder  activity  is  around  23  °.  Under  Sea-state  8 
the  heading  is  maintained  to  an  accuracy  of  around  0.2  °  while  the  rudder  activity  is 
around  7°. 

It  is  this  rudder  activity  which  must  be  reduced  whilst  maintaining  reasonable  heading 
accuracy. 

7.2  ContnUer  design  using  frequency  dependent  weighting 

In  this  section  the  control  signal  weighting  function  will  be  selected  to  minimize 
rudder  activity  at  high  ftequency. 

Consider  the  frequency  responses  of  the  three  wave  spectra  in  Fig.  7.  It  is  clear  that 
control  weighting  is  necessary  in  the  frequency  range  0.1  to  1  rad/s. 

It  is  desired  to  shape  F^.  such  that  it  has  a  low  value  at  low  frequency  and  rising  quickly 
in  the  range  0.1  to  1  ra^s  and  maintaining  a  constant  value  as  m  m. 

Let  Fq  be  defined  as: 


S^+fjS+fj 


(14) 


This  is  similar  in  form  to  the  output  disturbance  model  (4).  However  an  extra  s  is  included  in 
the  numerator  to  ensure  a  non-zero  value  of  F^,  as  ©  — » oo.  Once  sensible  values  have  been 
chosen  for  fj,  {2,  f3  then  the  k^  term  may  be  adjusted  as  a  design  parameter. 

With  k^  =  1,  suitable  values  for  f|,  f2,  f3  were  determined  to  be  fi  =  140.175,  f^  =  0.144, 
^  =  0.274.  Using  the  bilinear  transformation,  the  following  discrete-time  control  wnghting 
function  was  obtained: 


p  (^1)  ■  122.918-245.  836z'  ^•t-122.918z~ 
1-1.634z'‘40.874z'2 


(15) 


The  frequency  response  of  this  weighting  function  is  in  Fig.  15. 

The  generalized  Hoo  controller  was  determined.  The  parameters  arc  shown  in  Table.  7. 
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Fjg.  16a  shows  the  yaw  angle  obtained  with  the  course-keeping  controller  under 
Sea-state  3.  The  heading  is  maintained  to  an  accuracy  of  around  0.2°  which  is  clearly  worse 
than  with  the  course-changing  controller.  However,  the  rudder  activity  has  been 
significantly  r^uced  to  variations  of  around  0.15°  A  similar  effect  is  obsered  for 
Sea-State  8,  (Figs.  17a  and  17b).  The  heading  error  is  around  0.3°  which  is  only  slightly 
greater  than  with  the  course-changing  controller.  However,  the  rudder  activity  has  been 
significantly  reduced  to  around  0.3  °. 

7 .4  Robustness  with  respect  to  speed  variations 

In  Ais  s^don,  the  efiect  of  speed  variation  on  the  course-keeping  controller  is  observed; 
forclantyonly  Sea-state  3  will  be  considered. 

It  is  clear  from  Figs.  18  and  19  that  the  high  frequency  movement  of  the  ship  is  more 
pronounced  at  the  higher  speed  of  8  m/s. 

8.  Conclusions 

Two  Hoo  autopilots  have  been  presented  ;  one  for  course-changing  mode  and  one  for 
course-keeping  mode.  The  course-changing  autopilot  provides  responsive  control  action  for  a 
good  step  response  and  to  counteract  the  effects  of  disturbance  due  to  the  wind  and  waves. 
The  course-keeping  autopilot  provides  less  accurate  heading  performance  in  the  presence  of 
waves  but  the  rudder  activity  is  significantly  reduced. 

The  Ho,  autopilot  design  procedure  provides  very  good  stability  robusmess  with  little 
effort  in  selection  of  weighting  functions. 

Both  autopilots  have  shown  to  be  very  robust  with  respect  to  speed  variations.  The  ship 
considered,  however,  is  not  intended  as  a  highly  manoeuvrable  craft  and  does  not  have  a  very 
large  speed  range.  Modem  warships  have  a  latter  speed  range.  Further  work  will  be 
necessary  to  evaluate  the  robustness  of  the  H,o  autopilot  with  a  larger  speed  range. 

A  very  simple  linear  model  of  the  ship  is  assumed  in  this  paper.  Furthermore  the  ship 
transfer  function  parameters  are  assumed  to  vary  only  with  speed.  However,  they  will  vary 
also  with  other  parameters  such  a  with  magnitu^  of  rudder  movement  and  with  loading.  In 
addition,  the  centre  of  gravity  of  the  ship  will  almost  certainly  not  be  at  the  geometric  centre 
because  of  asymmetry  and  loading.  However,  these  complexities  are  not  considered  in  this 
paper. 
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Model 

Speed  (m/s) 

K  (1/s) 

T(s) 

1 

3 

0.03 

73.5 

2 

5.42 

0.0542 

40.6 

3 

8 

0.08 

27.5 

Table  1  -  Ship  Model  parameters 
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2.027 

1.014 

-1.986 

0.986 

2 

5.42 

6.58 

3.290 

-1.976 

0.976 

3 

8 

■AkJ 

14.255 

7.127 

-1.964 

0.964 

Table  2  -  Discrete-tune  model  parameters 
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Table  6  -  Generalized  H  controller  parameters 
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figure  1  -  Ship  CO 
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Figure  3  ■■  Rudder  motion  model 
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Figure  5  ™  Block*'shepe<j  ship  in  vsves 
(after  Blanke  (1981)) 
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Figure  6  -  Frequency  response  of  ship  models 


Figure  8  -  Open-loop  frequency  response  with  Generalized  H-inf 
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Figure  10 


Figure  11 


Figure  16a 


MOOeR  ANCLE:  SgA>$T^T£ 


COMPUTER  AIDED  DAMAGE  STABILITY  CONTROL  IN  THE  M-CLASS  FRIGATE 
OF  THE  ROYAL  NETHERLANDS  NAVY 


by  W.  van  Nes, 

Royal  Netherlands  Navy 
R .  Moerman 

Van  Rietschoten  &  Houwens 


ABSTRACT 

Damage  Control  (DC)  management  needs  information  about  the 
stability  and  buoyancy  of  the  ship.  This  information  is  based  on 
the  integrity  of  the  ship's  hull  and  the  loading  condition  and  is 
the  result  of  a  number  of  calculations. 

Up  till  now  the  required  stability  information  was  derived  by  the 
DC  officer  from  standard  damage  stability  data  sheets,  which  are 
only  available  for  a  limited  number  of  damage-,  wind-  and  loading 
conditions.  But  in  the  M-class  frigate  the  calculations  are 
performed  within  the  Integrated  Monitoring  and  Control  System 
(IMCS)  which  offers  a  user  friendly  man  machine  interface  for  all 
platform  systems. 

The  Stability  Calculation  Module  for  the  M-class  IMCS  consists  of 
three  functions: 

a.  Damage  stability  calculation;  to  derive  actual  state 
stability  data  and  final  state  stability  data  if  no  DC  counter¬ 
measure  will  be  carried  out.  The  system  will  also  check  whether  the 
operational  stability  criteria  will  be  met,  i.e.  if  wind  and  roll 
movements  are  taken  into  account . 

b.  Damage  stability  evaluation;  in  order  to  evaluate  the  result 
of  possible  DC  counter-measures.  The  operator  can  enter  his 
proposed  counter-measures  into  the  system  which  will  then  calculate 
the  new  final  state  stability. 

c.  Stability  indication  calculation;  in  order  to  to  derive  a 
quick  rough  stability  indication  based  on  roll  movements.  This 
indication  will  be  used  if  not  all  the  required  inputdata  for  the 
stability  calculations  are  available  or  reliable,  or  if  there  are 
too  many  influencing  factors  such  as  severe  damage,  heavy  icing  or 
fire  fighting  waste  water. 
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The  Stability  Calculation  Module  supplies  the  DC  officer  with  the 
information  he  needs  to  make  accurate  decisions,  with  a  minimum  of 
manual  input,  and  is  operated  as  an  integrated  part  of  his  platform 
management  workstation. 

1 .  INTRODUCTION 

If  we  consider  a  navy  vessel  to  be  a  system,  the  major  system 
functions  that  can  be  distinguished  are,  in  order  of  importance: 

-  to  stay  floating; 

-  to  remain  underway; 

-  to  retain  its  mission. 

The  primary  function,  floating,  is  accomplished  by  buoyancy  and 
stability.  However,  the  buoyancy  and  the  stability  of  the  ship  can 
be  threatened  by  calamities  such  as  a  collision  or  a  hit  of  a 
torpedo,  a  mine  or  a  missile.  To  enable  the  damage  control  managers 
to  deal  effectively  with  these  threats,  the  managers  must  be 
quickly  provided  with  accurate  and  detailed  information  about  the 
situation,  so  that  they  can  counter  the  threats  by  taking 
appropriate  active  measures.  Passive  measures  have  already  been 
taken  in  the  design  of  the  hull  geometry  and  compartimentation  as 
well  as  in  the  weight  distribution  on  board. 

Till  now,  the  Damage  Control  (DC) -officer  derived  the  stability 
information  that  he  needed  for  decisions  about  weight  distribution 
or  about  the  appropriate  counter  measures  in  case  of  calamities, 
from  standard  damage  stability  data  sheets,  on  which  only  a  limited 
number  of  damage-,  wind  and  loading  conditions  were  described.  On 
top  of  that,  the  described  conditions  were  not  the  operational 
conditions,  but  were  mainly  the  functionally  required  conditions  as 
specified  in  the  contract  design. 

With  these  datasheets,  the  DC-officer  had  to  compile  the  actual 
stability  situation  by  means  of  calculations,  while  also 
coordinating  the  damage  control  actions  throughout  the  ship  at  the 
hectic  location  of  the  combined  Ships  Control  Centre  (SCO  and  the 
NBC-and  DC-headquarters .  Also,  the  datasheets  did  not  describe 
situations  in  which  there  occurs  severe  icing  or  an  excessive 
amount  of  water  caused  by  firefighting  and  boundary  cooling. 
Experience  on  the  USS  Stark  and,  more  recently,  on  the  Scandinavian 
Star,  has  proved  that  the  effects  of  these  occurrences  are  of  great 
influence  in  actual  situations. 

The  M-class  frigate  is  equipped  with  an  Integrated  Monitoring  and 
Control  System  (IMCS) .  This  system  processes  platform  sensor  input 
that  is  displayed  on  workstations  in  the  SCC  via  which  the  operator 
can  also  enter  commands  for  platform  actuators.  As  the  input  for 
the  stability  calculations  was  already  available  in  the  IMCS,  it 
was  decided  to  integrate  the  stability  calculations  in  the  IMCS  of 
the  M-class  Frigate. 
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In  the  M-class  frigate,  the  calculations,  which  are  based  on  a 
model  of  the  ship  and  carried  out  within  the  IMCS,  are  performed  in 
such  a  way  that  even  complex  situations  can  be  analized.  At  the 
same  time,  the  system  also  provides  the  necessary  sensor  input  as 
well  as  an  user-friendly  man-machine  interface  in  which  the 
monitoring  and  control  of  platform  systems  and  the  stability 
management  are  integrated  in  such  a  way  that  the  operator  does  not 
loose  grip  on  the  situation.  This  reduces  the  workload  of  the  DC- 
officer  and  enables  him  to  simultaniously  manage  damage  control  and 
stability.  Although  the  stability  calculation  module  is  a  decision 
support  system,  it  is  not  an  expert  system. 

2.  THE  M-CLASS  INTEGRATED  MONITORING  AND  CONTROL  SYSTEM 


Figure  2.1  M-Class  frigate  IMCS  configuration 
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Figure  2.3  SCO  Operator  Workstations 

For  their  monitoring  and  control  tasks,  the  three  platform 
operators  can  dispose  of  three  VDO's.  On  one  VDU,  there  is  a 
display  of  an  alarmtable  which  contains  a  list  of  the  relevant 
alarms  for  that  particular  position.  The  operators  can  also  request 
mimic  VDU  presentations  from  a  set  of  mimics.  Mimics  are  drawings 
of  platform  systems  in  which  the  current  state  of  a  system  is 
represented.  Furthermore,  the  operators  may  request  several 
general  information  presentations  concerning  components  or  parts  of 
platform  systems  on  their  VDU’s.  The  DC  operator  may  also  use  a  set 
of  DC  plot  presentations  of  the  current  situation  in  the  ship.  In 
these  DC  plot  presentations,  damage  information  derived  from  human 
observation  is  entered  graphically  through  a  workstation  at  the  DC 
section  station,  or  at  the  SCC.  This  information  is  integrated  with 
the  automatic  sensor  information.  To  avoid  communication  errors, 
the  same  presentations  are  available  in  the  DC  section  stations,  in 
the  SCC  and  in  the  CIC.  This  information  is  also  used  as  input  for 
the  damage  stability  calculations. 

3.  THE  M-CLASS  STABILITY  CALCULATION  MODULE 

The  M-Class  Stability  Calculation  Module  consists  of  three  parts, 
as  shown  in  figure  3.1: 
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The  IMCS  of  the  M-class  frigate  is  a  decentralized  computer  network 
which  basically  consists  of  four  parts  as  shown  at  fig  2.1; 

-  the  control  units; 

-  the  local  processing  units; 

-  the  cental  processing  unit; 

-  the  workstations. 

The  control  units  have  the  possibility  to  monitor  and  control  a 
platform  system  independently.  In  the  local  processing  units,  which 
are  located  thoughout  the  ship  in  the  vicinity  of  sensors  and 
actuators,  the  sensor  data  is  being  processed  and  sent  to  the 
redundant  central  processing  unit  where  the  sensor  data  is 
processed  further  in  order  to  get  integrated  information  on  system 
level.  Operators  can  get  a  presentation  of  this  system  information 
on  their  workstations  and  they  can  also  enter  commands  concerning  a 
platform  system  by  means  of  their  workstations. 

The  workstations  are  placed  in  the  SCO,  in  the  Combat  Information 
Centre  and  in  the  DC  section  stations  fore  and  aft,  as  shown  in  fig 
2.2.  The  DC-operator  in  the  SCC  has  a  three-VDU  workstation  and 
this  also  holds  for  the  propulsion  operator  and  the  electrical 
operator  as  shown  at  fig  2.3.  Both  the  DC-off icer  and  the  NBCD- 
officer  have  a  single-VDU  workstation  and  this  also  holds  for  the 
DC  section  stations.  The  commander  in  the  Combat  Information  Centre 
also  has  a  workstation  but  this  workstation  does  not  offer  the 
possibility  of  entering  commands. 


Station  aft  Control  Centre  station  fwd 

Figure  2.2.  General  location  of  the  IMCS  workstations 
in  a  frigate 
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Figure  3.1  Overview  of  the  Stability  Calculation  Module 

-  The  calculation  of  the  initial-  and  final  state 

stability,  based  on  the  current  situation.  The  initial 
state  represents  the  condition  of  the  ship  at  the  moment 
of  calculation  and  the  final  state  represents  the 

equilibrium  condition  of  the  ship  that  will  be  reached  if 
no  corrective  actions  ate  taken. 

These  calculations  can  be  divided  into  the  following 
subsystems : 

•  the  processing  of  sensor  data  into  platform 
information,  this  is  a  standard  IMCS  function; 

•  the  validation  of  automatic  sensor  input  for  the 
stability  calculations  by  the  operator; 

•  the  calculation  of  initial  and  final  state  stability; 

•  the  presentation  of  stability  information; 

-  The  calculation  of  the  initial-  and  final  state 

stability,  based  on  the  actual  situation  and  a  number  of 
counter  measures;  the  latter  can  be  divided  into  the 
following  subsystems; 

•  the  input  of  counter  measures  by  the  operator; 

•  the  calculation  of  final  state  stability  with  counter 
measures; 

•  the  presentation  of  stability  information  with  counter 
measures; 
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-  The  stability  indication  calculation,  producing  the 
metacentric  height,  based  on  the  roll  movements  of  the 
ship. 

4 .  VALIDATION 

The  results  of  a  calculation  are  worthless  if  there  is  an  error  in 
the  input  of  the  calculation.  In  case  of  a  decision  support 
system,  the  system  is  only  usable  if  the  user  trusts  its  output.  If 
the  DC  officer  does  not  trust  the  result  of  a  stability  calculation 
which  is  done  by  a  system,  the  implementation  of  such  a  system  has 
a  negative  effect  on  the  performance  of  the  DC  officer  instead  of 
reducing  his  uncertainty  about  the  situation,  the  system  gives  him 
one  more  reason  to  worry. 

To  make  the  stability  calculation  module  a  useful  and  powerful  tool 
for  the  DC  officer,  the  module  offers  a  validation  of  the  input- 
data  that  are  used  for  the  calculations.  This  enables  the  officer 
to  maintain  control  of  this  module  in  such  a  way  that  it  does  not 
increase  his  workload. 

The  validation  can  be  done  by  both  the  DC  officer  and  the  DC 
operator.  The  actions  that  can  be  performed  to  carry  out  the 
validation  process  are: 

-  For  each  (tank)  compartment,  the  operator  can  decide 
whether  the  representation  of  the  situation  by  the 
digital  readout  of  the  sensor  is  correct.  If  there  are  no 
sensors  in  in  a  compartment,  or  if  the  sensors  are  out  of 
order,  or  it  is  decided  that  the  representation  is 
incorrect,  the  operator  can  enter  a  replacement  value, 
based  on  actual,  local  observation.  The  operator  can 
also  change  the  value  of  the  specific  weight  of  the 
contents  of  a  tank. 

-  For  each  (tank)  compartment  the  operator  can  decide 
whether  it  is  damaged.  Information  about  damage  is  based 
on  the  plot  symbols  that  are  plotted  on  the  DC  plots  by 
the  repair  units  and  on  direct  reports  from  his 
sectionleader .  In  case  of  damage,  the  compartment  status 
"damaged"  is  entered  into  the  system  by  the  operator 
after  which  the  stability  calculation  can  be  made. 

-  The  operator  can  decide  whether  wind  speed,  wind 
direction  and  the  heeling  angle  as  are  shown  by  the 
digital  readout  of  the  sensors,  are  correct.  If  the 
operator  decides  that  the  reading  is  wrong,  the  operator 
can  enter  a  replacement  value. 
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-  when  a  sensor  for  which  the  operator  has  entered  a 
replacement  value  works  correctly  again,  it  is  possible 
for  the  operator  to  decide  to  remove  the  replacement 
value.  To  be  able  to  see  the  difference  between  sensor- 
input  and  operator-input,  the  source  is  shown  at  any 
reading. 

5.  THE  M-CLASS  MMI  PHILOSOPHY 

The  M-class  frigate  man-machine  interface  philosophy  is  based  on 
"interfacing  through  presentations".  This  means  that  information 
for  the  use  of  operators  can  be  retrieved  from  a  predefined  set  of 
presentations  and  that  input  can  only  consist  of  adaptations  which 
are  entered  by  means  of  a  presentation.  As  the  stability 
calculation  module  is  an  integrated  part  of  the  IMCS,  the 
"interfacing  through  presentations"  is  also  implemented  here.  There 
are  seven  presentations  defined  for  the  stability  calculation 
module ; 


-  actual  state  stability  presentation.  This  presentation 
contains  the  current  dynamic  values  that  are  the  input 
for  the  stability  module.  This  presentation  is  used  for 
the  validation  of  the  input; 

-  stability  input  presentation.  This  presentation  contains 
the  static  values  which  were  the  input  for  the  last 
stability  calculation; 

-  initial  state  stability  presentation.  This  presentation 
contains  the  initial  state  graph, 

which  is  a  result  of  the  last  stability  calculation; 

-  final  state  stability  presentation.  This  presentation 
contains  the  final  state  graph, 

which  is  a  result  of  the  last  stability  calculation; 

-  manipulation  presentation;  this  presentation  contains  the 
input  values  that  were  the  input  for  the  last  stability 
calculation.  This  presentation  is  used  for  the  input  of 
the  countermeasures  that  have  to  be  evaluated; 

-  final  state  manipulation  presentation.  This  presentation 
contains  the  final  state  graph 

which  is  a  result  of  the  last  stability  calculation  based 
on  the  countermeasures  that  have  to  be  evaluated; 

-  stability  parameter  presentation.  This  presentation 
contains  the  parameters  for  the  stability  calculation 
module  that  do  not  frequently  change  but  that  are 
affected  by  the  use  of  the  ship.  Examples  of  such 
parameters  are  the  displacement  under  standard  loading 
conditions  and  the  weight  of  ammunition. 
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A  presentation  request  or  a  change  in  a  presentation  is  not  linked 
in  any  way  to  the  start-command  for  the  stability  calculation.  The 
operator  may  switch  a  number  of  times  between  stability 
presentations  and  other  presentations  before  starting  the  stability 
calculation.  It  is  also  possible  that  part  of  the  validation 
process  is  performed  by  another  operator  ("multi  tasking")  .  To 
enable  the  operator  to  use  the  presentations  in  this  way,  he  needs 
a  simple  and  direct  interaction  that  requires  only  a  minimum  of 
operator-action . 

5-.  I.  ££aaefl£atj,im  -naqiiest 

Because  the  presentation-request  forms  the  start  of  every  operator- 
action  and  because  the  request  can  be  made  in  every  possible 
situation,  the  operator  can  identify  the  presentation-group  by 
means  of  a  single  function  key  on  his  functional  keyboard.  Examples 
of  a  presentation-group  are:  mimic  presentations,  stability 
presentations  and  DC  plot  presentations.  For  stability 
presentations  there  is  a  key  marked  "stability".  After  pressing 
this  button,  the  operator  is  provided  with  a  short  menu  of  the 
possible  presentations  within  the  group.  The  menu  will  appear  at 
the  bottom  of  his  screen  and  in  this  case,  the  menu  will  consist  of 
the  above  mentioned  presentations. 

The  operator  can  choose  from  this  menu  by  indicating  his  choice 
with  a  trackball  cursor  or  by  pushing  the  concerning  function  key. 
The  dialogue  is  finished  by  entering  the  "execute"  command  with  a 
function  key. 

5..2..  Opebahox  input 

The  object  of  the  operator  input  can  indicated  with  a  trackball 
Cursor.  When  an  operator  has  selected  an  object  in  this  way,  then 
the  relevant  Information  about  this  object  is  presented  at  the 
bottom  of  his  screen,  together  with  a  menu  of  possible  commands.  A 
command  can  be  selected  by  pointing  it  out  with  a  trackball  cursor 
or  by  pushing  the  concerning  function  key.  If  the  object  is  a 
numerical  value,  the  operator  can  enter  a  (new)  numerical  value 
with  a  numerical  keypad. 


6.  ACTUAL  STATE 

With  the  actual  state  stability  presentation,  as  shown  in  figure 
6.1,  the  operator  can  perform  the  validation  process,  so  that  a 
reliable  output  of  the  stability  calculation  module  is  ensured. 

This  presentation  contains  the  input  data  for  the  stability 
calculation  module 

-  for  each  compartment ; 

•  the  relevant  information  that  is  required  to  enable  the 
operator  to  identify  the  data; 
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-  the  identification  code  of  the  compartment, 

-  the  name  of  the  compartment, 

•  the  basic  status  information; 

-  the  level  of  liquid  in  a  compartment; 

-  the  specific  weight  of  the  liquid  in  a  compartment; 

-  the  indication  "damaged"; 

-  the  source  of  the  information; 

•  additional  information  as  drawn  on  the  DC  plot 
presentations  as  "water  level"  and  "damaged". 

-  the  heeling  angle; 

-  the  relative  wind  speed; 

-  the  relative  wind  direction. 
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Figure  6.1.  The  actual  state  presentation 

The  operator  can  alter  the  input  data  for  the  stability  calculation 
module  by  selecting  the  item  with  the  trackball  cursor  and  by 
replacing  it  with  a  correct  value.  If  he  switches  between  several 
presentations  in  order  to  obtain  situation  information  or  to  handle 
other  problems,  the  altered  input  data  remains  stable.  Eventually, 
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when  the  operator  agrees  with  the  situation  he  has  created  in  this 
presentation,  he  can  start  the  stability  calculation  again  by 
selecting  the  name  of  the  presentation,  followed  by  entering  the 
"start"  command. 

7 .  CALCULATION  OF  INITIAL  AND  FINAL  STATE 

The  stability  calculation  is  devided  into  two  separate,  but 
identical  parts; 

-  the  calculation  of  the  initial  state;  this  is  the 
condition  of  the  ship  at  the  moment  that  the  calculation 
is  made . 

-  the  calculation  of  the  final  state;  this  is  the 
equilibrium  condition  of  the  ship  that  will  be  reached  if 
no  corrective  actions  are  taken. 

7.1.  Calculation  of  the  initial  state 

The  calculations  are  based  on  a  mathematical  model  of  the  ship  in 
the  form  of  a  number  of  polynomes.  These  polynomes  have  been 
precalculated  with  the  hydrostatic  package  SIKOB  for  the 
hydrostatics  of  the  hull  and  the  compartment  parameters  as  a 
function  of  (sensor)  sounding  values.  The  polynomes  are  stored  in  a 
database  in  the  form  of  polynome  coefficients  and  the  required 
values  are  obtained  by  interpolation  with  the  Horner  method. 

The  database  also  contains  a  number  of  other  data  items  like 
parameters  for  positions  of  openings  in  the  hull  and  on  the 
bulkhead  deck.  The  parameters  for  the  calculation  of  the 
aerodynamic  loads  are  derived  from  measurements  on  a  model  M-class 
frigate  in  a  windtunnel  of  the  Dutch  Aerospace  Laboratory  (NRL)  . 

Both  wind  force  and  point  of  application  have  been  determined. 

The  calculations  consist  of  four  parts: 

-  calculation  of  draught  and  trim; 

-  calculation  of  righting  and  heeling  arms; 

-  calculation  of  the  heeling  angle; 

-  calculation  of  stability  margins. 

a.  Calculation  of  the  draught  and  trim 
The  validated  sounding  data  will  be  converted  to  basic  soundings, 
representing  the  liquid  level  that  is  independent  of  the  heeling 
angle.  Based  on  these  basic  soundings,  the  sum  of  liquid  loads, 
momentums  and  the  effect  of  the  free  liquid  surfaces  are 
calculated.  The  calculation  uses  curves  which  are  stored  in  the 
database  and  are  shown  in  figure  7.1.  The  weight  of  food  supplies 
and  ammunition  is  assumed  to  be  proportional  to  the  weight  of  the 
liquid  loads  and  is  considered  to  be  a  relatively  static  factor.  As 
such,  the  weight  of  food  supplies  and  ammunition  is  taken  into 
account  in 
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Figure  7.1  Curves  used  for  calculation  of  compartment  data 

the  calculations.  Based  on  these  loading  conditions,  the 
displacement,  the  center  of  gravity  are  calculated. 

The  draught  and  trim  will  be  derived  from  the  curves  of  the  draught 
and  of  the  longitudinal  center  of  buoyancy  as  a  function  of 
displacement  and  trim,  as  is  shown  in  fig  7.2. 

The  metracentric  height  will  be  calculated  in  the  same  way.  (Also 
see  7.3) 
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Figure  7.3  Curves  used  for  calculation  of  matacentric  height 

b.  Calculation  of  right ino  and  heeling  arms 
The  righting  and  heeling  arms  are  calculated  on  the  basis  of  the 
displacement,  trim  and  the  effect  of  the  free  liquid  surfaces. 

The  arms  that  are  calculated,  are  the  arms  of  the  righting  and 
heeling  momentum  with  the  weight  of  the  ship  as  a  unit  force. 

The  righting  arm  is  the  horizontal  distance  between  the  center  of 
gravity  and  the  center  of  buoyancy.  The  metacenterpoint  is  the 
point  of  intersection  of  the  righting  force  and  vertical 
centerplane.  Crosscurves  are  used  for  the  ca’lculation  of  righting 
arms.  The  crosscurve  equals  NK  *  sin  (PHI)  and  is  stored  in  the 
database  as  a  function  of  displacement  and  the  longitudinal  center 
of  buoyancy.  (Also  see  figure  7.4  ) 

Based  on  the  )cnown  displacement  and  the  position  of  the  center  of 
gravity,  the  righting  arms  can  be  calculated  with  the  crosscurve 
polynomes  from  the  database.  (Also  see  figure  7.5) 

The  heeling  arm  caused  by  free  liquids  is  derived  from  the 
transversal  momentum  of  inertia  of  the  liquid  surface,  which  is 


3.349 


stored  as  a  polynome  in  the  database  as  a  function  of  the  basic 
sounding.  (Also  see  figure  7.6) 

The  heeling  arm  caused  by  wind  is  derived  from  the  relative  wind 
speed  and  from  direction  data  in  combination  with  the  results  of 
the  aerodynamic  scale  measurements  that  are  stored  in  the  database 
The  point  of  application  of  the  reactionforce  is  assumed  to  be  on 
half  draught.  (Also  see  figure  7.6) 


c.  Calculation  of  the  heelin(y  angle 

The  angle  of  heel  can  be  derived  by  calculating  the  angle  at  which 
the  righting  arm  equals  the  total  of  heeling  arms. 

d.  Calculation  of  the  stability  margins 

The  buoyancy  margins  are  expressed  by  freeboard  which  is  derived  by 
calculating  the  vertical  distance  from  every  opening  in  the  ship's 
structure  to  the  waterline  and  from  a  number  of  positions  on  the 
bulkhead  deck  to  the  waterline.  The  smallest  distance  is  the 
resulting  freeboard.  The  location  of  the  positions  used  in  the 
calculations  is  stored  in  the  database. 

Usually,  stability  criteria  are  based  on  the  design  criteria,  so, 
the  conditions  in  the  damage  stability  data  sheets  are  predefined 
and  independent  of  environment.  However,  stability  criteria  are 
essential  for  survival  under  given  circumstances  in  real-life 
situations.  Therefore,  the  operational  stability  criteria  that  are 
used  here,  are  based  on  Goldberg  and  Sarchin  (5)  and  that  resulted 
in  the  formulation  of  operational  criteria  that  take  the 
environmental  conditions  such  as  wind  and  roll  movements  into 
account . 

The  stability  criteria  that  are  used  ,j  ■ 

-  maximum  significant  roll  ang.- 

-  maximum  wind  arm; 

-  minimum  metracentric  height. 

The  allowable  toll  angle  is  limited  by  the  angle  at  which  the 
openings  reach  the  water  level  during  the  roll  movements  of  the 
ship.  Besides  that,  the  significant  roll,  which  is  a  measure  for 
the  dynamic  energy  of  roll  movements,  may  not  exceed  the  value  that 
represents  the  potential  engergy  of  the  righting  moment.  This  value 
is  determined  by  the  ratio  of  the  size  of  the  areas  A1  and  A2  and 
by  the  roll  movement  safety  factor,  as  shown  in  figure  7.7. 
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Figure  7.7  Righting  and  heeling  arms  as  function  of  the 
heeling  angle  with  tht  operational  criteria 

The  stability  should  be  sufficient  to  withstand  a  gust  of  wind. 
Therefore,  the  ratio  of  the  the  arm  caused  by  wind  and  the  maximum 
achievable  wind  arm  (RAMAX) ,  as  shown  in  figure  7.7,  should  be  less 
than  the  wind  safety  factor. 

The  metracentric  height  should  always  be  positive  and  should  have 
minimum  value. 

In  the  M-class  frigate  the  safety  factor  for  roll  movements  is 
determined  at  1.4,  the  safety  factor  for  wind  at  0.6  and  minimum 
value  for  metracentric  height  at  0.05  meters. 

7.2  Calculation  of  the  final  state 

The  final  state  stability  calculations  are  based  on  the  added 
weight  method  which  results  in  an  iterative  process.  A  damaged 
compartment  is  assumed  to  be  in  open  connection  with  the  sea.  This 
assumption  leads  to  a  final  state  situation  in  which  the  original 
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liquid  contents  of  the  damaged  compartment  has  disappeared  into  the 
open  sea  and  the  compartment  is  filled  with  seawater  up  to  the 
known  waterline.  The  tanksoundings  of  the  flooded  compartment  are 
calculated  with  the  draught  trim  and  heeling  angle  of  the  last 
iteration.  The  difference  in  mass  and  momentum  of  the  water  in  the 
flooded  compartment  is  added  to  the  mass  and  momentum  of  the  ship. 
With  the  new  displacement  and  new  center  of  gravity  and  the  total 
effect  of  free  liquids,  the  new  trim  draught  and  heeling  angle  can 
be  calculated  and  used  for  the  next  iteration. 

The  final  state  will  be  reached  if  the  draught,  trim  and  heeling 
angles  do  not  alter  more  than  a  given  tolerance. 

8.  PRESENTATION  OF  STABILITY  INFORMATION 

In  the  initial  and  final  state  presentations,  the  stability  data  is 
made  visible  to  the  damage  control  management.  Primarily,  this  is 
done  graphically  and  is  supported  by  a  small  number  of  stability 
and  buoyancy  margins  in  a  digital  readout .  If  the  margins  do  not 
meet  the  criteria,  the  operator  receives  a  warning.  Usually,  naval 
constructors  make  stability  data  visible  by  presenting  stability 
arms  as  a  function  of  the  angle  of  heel.  This  presentation  method 
is  also  applied  for  the  stability  calculation  module.  In 
conventional  stability  data  sheets,  only  the  stability  arms  for  one 
side  are  presented,  showing  the  worst  case.  However,  the  results  of 
the  stability  calculation  module  have  to  be  shown  to  SB  and  PS  for 
both  angles,  so  as  to  give  the  operator  a  complete  view  of  the 
situation.  (Also  see  figure  8.1) 
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Figure  8.1.  Initial  state  stability  presentation 
9.  MANIPULATION 

To  assist  the  DC  officer  in  his  stability  management  tasks,  an 
attempt  has  been  made  to  provide  solutions  for  damage  stability 
cases  with  an  expert  system.  The  results  of  these  attempts  made 
clear  that  it  took  a  long  time  to  process  the  whole  range  of 
possibilities  and  that  the  results  were  unpredictable. 

Therefore,  an  evaluation  function  has  been  added  to  the  stability 
calculation  module.  This  evaluation  function  is  a  powerful  tool 
for  the  DC  officer  to  evaluate  the  possible  counter  measures  and  it 
enables  him  to  take  adequate  actions  without  delay.  In  this  way, 
solely  the  damage  control  managers  remain  responsible  for  the 
actions  that  have  to  be  taken. 

By  means  of  so-called  manipulation  commands,  corrective  actions  and 
their  effect  on  the  ship's  stability  can  be  simulated  by  the 
stability  calculation  module.  The  aim  of  counter  measures  is  to 
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create  a  better  stability  and  buoyancy.  The  actions  that  can  be 
taken  into  account  in  order  to  reach  this  goal,  are  the  actions 
that  create: 

-  a  heeling  moment  which  reduces  the  heeling  angle; 

-  a  trimming  moment  which  increases  freeboard; 

-  a  low  position  of  the  center  of  gravity  which  increases 
the  righting  moment. 

For  this  purpose,  the  DC  officer  can  enter  four  commands  for  each 
compartment  into  a  presentation  that  is  similar  to  the  actual  state 
presentation : 

-  ballast  with  seawater; 

-  transfer  of  liquid  load; 

-  de-watering; 

-  counter  flooding. 

The  manipulation  function  creates  a  manipulated  set  of  compartment 
soundings  and  this  set  is  used  as  input  for  a  final  state  stability 
calculation . 

10.  STABILITY  INDICATION  CALCUL.ATION 

This  calculation  can  be  used  if,  due  to  exceptional  conditions,  no 
reliable  calculation  can  be  made.  Exceptional  conditions  are, 
amongst  others; 

-  severe  icing; 

-  extreme  wastewater  problems  due  to  firefighting; 

-  severe  damage  to  the  ships  sections. 

With  this  calculation  the  metacentric  height  can  be  derived  from 
the  roll  movements  of  the  ship  using  the  known  "pendulum  formula". 
The  circle  frequency  with  the  highest  amplitude  will  be  retrieved 
from  the  power  density  spectrum  of  rollmovements,  as  shown  in 
figure  10.1.  Then,  the  metacentric  height  will  be: 


In  which: 

GM  =  metacentric  height; 

I  =  transversal  radius  of  inertia; 

Si  =  circle  frequency; 

G  =  acceleration  of  gravity. 

Experiments  have  been  carried  out  on  board  of  the  Standard-class 
frigates  of  the  Royal  Netherlands  Navy.  From  these  experiments  an 
algorithm  has  been  derived.  This  algorithm  has  proved  to  be  very 
useful  if  applied  in  the  process  that  leads  to  a  reliable 
metacentric  height . 


3.356 


POWERSPECTRUM  ROLL  ANGLE  IN  DEGREES. 


in  1  r,  1.  ,  CIRCLE  FREOOENCT  IR  RRD'S 

Figure  10.1  Roll  angles  as  recorded  and  roll  spectrum  as 
calculated  during  the  BNLN  experiments 
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The  reliability  of  this  calculation  depends  on  the  processing  of 
sufficient  roll  data  and  on  the  applied  algorithm  that  was  found 
during  the  experiments  of  the  Royal  Netherlands  Navy  .  The 
reliability  of  this  calculation  is  only  influenced  externally  if 
the  ship  is  sailing  in  following  seas. 

11.  CONCLUSIONS 

Integration  of  the  stability  calculation  module  in  the  Integrated 
Monitoring  and  Control  System  is  necessary  because  through  this 
integration  it  is  possible  to  provide  direct  input  from  the  many 
sensors  and  the  automated  integrated  damage  control  plot  facilities 
to  the  stability  calculation  model  in  order  to  reduce  the  workload 
of  the  DC-operator  and  the  DC-officer. 

Knowledge  of  the  stability  of  ships  is  necessary  for  the  operator. 

The  stability  calculation  module  is  a  powerfull  tool  for  the  Damage 
Control  management  during  Damage  Control  operations.  Also,  the 
stability  calculation  module  is  an  important  factor  in  the  training 
of  the  technical  staff  as  it  enlarges  the  knowledge  of  stability 
and  leads  to  a  better  understanding  which,  in  their  turn,  result  in 
quick  and  adequate  corrective  actions  in  case  of  calamities. 
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COMBA.?  SYSTEM  DAMAGE  COMTEOD 


by  David  H.  Geer 
MKF  Engineering  Inc. 


1 .  ABSTRACT 

Ships  in  Mar  will  be  hit.  Fighting  hurt  means  post-hit 
firepower  having  a  capability  and  reaction  time  that  meets  the 
requirements  of  the  operational  coimander  both  for  terminal  defense 
and  area  defense/offense. 

In  order  for  the  combat  system  to  continue  to  fight  after 
battle  damage,  ship  control  and  auxiliary  systems  must  provide 
uninterrupted  vital  services  required  for  the  combat  system  as  well 
as  protecting  vital  spaces.  The  capability  to  Fight  Burt  involves 
both  the  physical  and  functional  survivability  of  not  only  the 
combat  system  but  the  ship  control  and  vital  systems  as  well. 

Emphasis  is  placed  on  the  fact  that  people  (ships  crew)  fight 
and  save  ships  using  the  tools  (systems,  equipments,  and 
procedures)  that  are  provided  them.  Thus,  every  capability  must 
have  the  fundamental  purpose  of  providing  a  "force  multiplier”  to 
the  crew  by  way  of  training,  organisational  coordination,  fighting 
hurt  procedures  and  decision  aids,  together  with  survivable  system 
design.  An  evolutionary  approach  to  improved  survivability 
employing  and  expanding  upon  current  highly  successful  and  proven 
techniques  is  described. 

2.  INTRODOCTION 

Fighting  Burt  is  the  recovery  of  the  combat  system  after 
battle  damage  by  reconfiguration  of  surviving  components  to  re¬ 
engage  threats  and  provide  terminal  defense  of  the  ship.  Major 
physical  damage  is  expected  to  the  targeted  ship  as  illustrated  in 
figure  1.  Because  the  combat  system  can  not  reasonably  be  hardened 
to  withstand  direct  weapon  inqtact  or  blast  effects,  the  emphasis 
is  placed  on  shock  and  fire  "hardening”,  redundancy  and  separation, 
and  thus  survivable  reconfiguration. 


3.359 


2x1 _ Post-hit  S<lt  Defense 


The  dsmsge  to  the  targeted 
ship's  Vital  Systems  and  Spaces 
must  be  minimised,  magasine 
explosion  precluded,  and  vital 
services  sustained  to  the 
surviving  combat  system  terminal 
defense  systems  and  weapon 
launchers. 

At  the  occurrence  of  battle 
damage,  it  is  imperative  that 
terminal  defense  systems  be 
supported  and  restored  as  a  high 
priority  since  the  ship  will  be 
highly  vulnerable  to  subsequent 
threat  weapon  salvos  and  raids. 

The  best  shipboard  damage  control  organisations  and  ship 
designs  can  be  overcome  by  subsequent  weapon  hits.  If  the  ship  has 
been  bit  once,  it  is  clearly  targeted.  Thus  the  ship's  combat 
system  must  be  prepared  to  re-engage  incoming  threats  as  rapidly 
as  possible. 

Figure  2  illustrates  the  need  for  rapid  combat  system  recovery 
to  engage  multiple  missile 
salvos  or  multiple  threat 
targeting  of  the  ship.  Ships 
performing  escort  or  convoy 
duties  can  be  expected  to  be 
separated  by  5  to  30  miles  from 
other  combatants.  Thus,  each 
ship  must  provide  for  its  own 

defense  against  "leakers" 

penetrating  the  screen.  Since 
enemy  engagement  doctrine 
typically  specifies  firing 
multiple  missile  salvos  at  a 
targeted  ship,  rapid  re¬ 

engagement  of  subsequent 
missiles  within  the  salvo 

interval  is  essential  for 

survival . 

2x2 _ Design  for  Damage 

Ship  combat  system  designs  and  procedures  optimise  pre-hit 
firepower.  The  design  process  and  procedures  are  well  defined  and 


Figure  1 
SHIP  DAMAGE 
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successful.  However,  ships  in  war  must  -05“ 

requires  the  extension  of  the  design  discipline  to 

hit  firepower.  Coping  with  battle  damage  requires  imediate, 

total -ship  coordination  and  prioritised  iV>eV  mUt  he 

and  equipments.  Command  decision  making  Vhll  but  on 

based  not  only  on  the  primary  damage  effects  to  the  ship, 
the  tactical  threat  and  residual  combat  system  capability. 

The  combat  system  dependency  on  the  ship’s  TOtE  system  and 
damagr  control  organisation  is  such  that  combat 
requires  integrated  resource  management  of  systems  and  personnel. 

The  relationships  between  all  elements  of  the  battle 

organisation  are  the  same  both  before  and  ®  ^"‘rff letted 

differ  however,  in  emphasis  and  manpower  allocation  as  retlectea 

in  table  I. 


Table  I 

CHANGING  EMPHASIS 


POST  -  HIT  CHANGING  EMPHASIS 

•  SUSTAIN  I  RESTORE  ELECTRCAl  POWER 

TO  COMBAT  SYSTEM 

•  SUSTAIN  /  RESTORE  VITAL  SERVICES 

•  PROTECT  VITAL  SPACES 

•  SUSTAIN  /  RESTORE  WEAPON 

ENGAGEMENT 


The  evolution  of  a  Fighting  Hurt 
capability  requires  total -ship  combat 
system  /  HM4E  system  survivability 
engineering.  In  the  far-term,  these 
changes  would  be  implemented  as 
total-ship  threat  reactive  control 
system  response,  redundancy  and 
dispersal  of  vital  components, 
survivable  connectivity,  and 

automated  decision  aids.  In 

addition,  a  long  term  commitment  to 
revisions  to  ship  procedures, 
doctrine,  training,  and 

organisational  relationships  is 
required.  _ _ 

3.  VITAL  SPACES  AND  SYSTEMS 

Fighting  Hurt  acknowledges  that  major  physical  damage  will 
occur  when  the  ship  is  bit.  The  statistics  and  ” 

battle  damage  from  World  War  2.  Korea,  Falklands,  and  the  Persian 
Gulf  are  clear.  Ships  are  seldom  lost  as  a  result  of  Primary  Damage 
(direct  blast  effects),  but  rather  as  a  result  of  Secondary  Damage 
(the  spread  of  fire  and  flooding  into  surrounding  areas). 

3.1  Vital  Spaces 

Vital  Spaces  are  defined  in  the  ship  specifications  and  ship's 
damage  control  books  as  "those  in  which  continued  operation  is 
essential  for  ship  control,  propulsion,  communications, 
seaworthiness,  and  fighting  capability  . 

representative  vital  spaces.  The  combat  system  vital  spaces  are 
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Tabl«  II 

located  throughout  the  VITAL  SPACES 
ship.  Protection  of 
combat  system  vital 
spaces  together  with 
propulsion,  electrical 
and  auxiliaries  vital 
spaces  is  of  paramount 
importance  to  post-hit 
fighting  capability. 

Nithin  the  context 
of  total  ship 
survivability,  priority 
must  be  given  to  saving 
vital  spaces.  They 
should  be  clearly 
identified  on  decision 
aids  and  accorded  the 
reaction  time  of 
response  required  to 
save  the  vital 
components  contained 
within.  One  example  will  suffice;  magazines.  Magazines  are  vital 
spaces.  Fire  in  the  vicinity  of  a  magazine  is  always  accorded  the 
highest  priority;  however,  flooding  and  structural  damage  are  not 
necessarily.  In  order  to  fight  hurt,  it  is  imperative  that  weapons 
be  kept  dry  and  debris  cleared  for  weapon  launch.  Nithin  each 
damage  control  zone  of  the  ship,  all  vital  spaces  should  be 
prioritized  with  respect  to  the  ships  current  tactical  situation 
and  the  type  of  damage  sustained. 

3.2  Vital  Systems 

The  Vital  Systems  sunsnarized  at  Table  III  are  essential  to  the 
operation  of  not  only  the  combat  system,  but  the  propulsion  and 
auxiliaries,  as  well  as  the  survival  of  the  ship  after  battle 
damage . 

While  all  vital  systems  are  essential  to  the  combat  system 
and  ship  survivability,  the  effect  of  an  interrupt  varies,  as 
reflected  in  the  ships'  Battle  Short  Doctrine.  The  range  of  time 
permissible  for  an  interrupt  to  the  combat  system  varies  from 
milliseconds  for  electrical  power  to  minutes  for  cooling  or  chilled 
water.  Additionally,  after  battle  damage,  the  effect  of  an 
interrupt  can  be  catastrophic  to  certain  vital  systems  such  as  the 
firemain,  with  men  engaged  in  firefighting  or  magazine  sprinkling 
due  to  fire. 


REPRESENTATIVE  VITAL  SPACES 


COMBAT  SYSTEMS 

PILOT  House 
CIt 

•kOlO  ROOM 
MISSILE  LAUNCHERS 
1C  A  GTRO 

POWtK  CONVERSION 
COMSAT  SYSTEM  EQMT  ROOMS 
SEARCH  RAOARS 

nabar  eomt  rooms 

ems  CONTROL  ROOMS 

Ctws  MAGAZINES 

SONAft  CONTfiOi^EOMTyCOOlWG 

NIXIE  ROOM 

CUN  DIRECTOR 


PROPULSION  ;lLEO_L^UX 

CENTRAL  CONTROL  STATION 

damage  control  central 

ENGINE  DOOMS 

AID  CONDITIONINS  ROOMS 

MACHINERY  ft  PUMP  ROOMS 

AUX  MACHINERY  ROOMS 

STEERING  GEAR  ROOM 

GENERATOR  ROOMS 

POWER  SUPPLY  /  CONVERSCN  ROOM 

ELECTRIC  LOAD  CENTERS 
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Table  111 

Casualty  reconfiguration  of  VITAL  SYSTEMS 
Vital  Systems  also  includes 
reducing  the  demand  (load) 
required  by  reduced  capacity 
caused  by  damage.  Electrical 
Load  Shed  is  a  prime  example  of 
the  necessity  to  rapidly  reduce 
electrical  load  in  accordance 
with  a  predetermined  and 
FLEXIBLE  doctrine.  Chill  Water 
an  example  of  the  need  to  reduce 
heat  load  by  reconfiguring  the 
combat  system  over  a  period  of 
minutes . 


4.  FUNCTIONAL  SURVIVABILITY  OP 
THE  BATTLE  ORGANIZATION 

Fighting  Hurt  requires 
prioritized  casualty  and  damage 
restoration.  Everything  can  not 
be  done  at  once.  Primary  damage  by  weapons  can  cause  25*40% 
personnel  casualties  on  a  destroyer  resulting  in  a  severe  shortage 
of  manpower.  This  can  be  especially  significant  in  the  area  of 
critical  technical  skills. 

The  crew  of  a  warship  fights  and  saves  its  ship  within  the 
framework  of  the  Battle  Organization.  The  Control  Positions  within 
the  Organization 
are  connected  by 
voice  and  data 
networks.  Figure 
3  illustrates  a 
typical  Condition  I 
Organization. 


The  success  of 
the  organization 
depends  in  large 
measure  upon  the 
survivability  of 
its  interior  voice 
and  data  links. 
The  sp^'ed  and 
completeness  with 
which  the 
organization  can 
decide  and  act  is 


BATTLE  ORGANIZATION 


VITAL  SYSTEMS 


•  ELECTRICAL  POWER  (400  HZ,  60  HZ 
flREMAIN 

MAGAZINE  5PRINICLING 

AFFF 

COOLING 

pun  I  U/ATPO 

OWN  SHIP  HEAD,  ROLL,  PITCH,  SPE 
WIND  SPEED,  DIRECTION 
RUDDER  ANGLE  INDICATION 
INTERIOR  COMMUNICATIONS 
VENTILATON  /  AIR  CONDITIONING 
COMPRESSED  AIR 
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dependent  on  the  information  and  displays  presented  to  the  decision 
makers  at  the  control  positions. 

4.1  Typical  Combat  System  Organisation  Deficiencies 

The  typical  combat  system  organization  reports  directly  to  the 
Tactical  Action  Officer  (TAO)  as  illustrated  in  figure  4.  The 
organization  that 
functions  in  this 
manner  has  the 
simplicity  of  each 
equipment  group  and 
its  operators 
reporting  directly 
to  the  warfare 
operators. 

The  battle 
damage  problem  with 
this  organization 
is  the  Electronics 
Casualty  Control 
(CASCON)  group  only 
communicates  with 
the  Electronic 
Technicians  and  the 
Data  Systems 
Technicians.  All 
other  repair 
personnel  report  directly  to  their  Warfare  Officers  and  the 
Tactical  Action  Officer.  The  lowest  cononon  denominator  for 
casualty  and  damage  coordination  is  the  Tactical  Action  Officer, 
not  the  Electronics  Casualty  Control  Group. 

In  a  battle  action,  the  TAO  and  Warfare  Officers  are  totally 
absorbed  with  the  threat  and  tactical  use  of  what  remains  of  the 
combat  system.  Further,  coordination  with  Engineering  &  Electrical 
Control  and  Damage  Control  Central  is  by  each  warfare  area  and 
Electronics  Casualty  Control;  five  different  areas  with  potentially 
five  different  sets  of  priorities.  During  battle  damage,  the  DCA 
and  Engineer  Officer  are  already  saturated  with  voice  and  data 
communications  within  their  own  areas  of  responsibility.  Further 
compounding  the  problem  is  the  fact  that  no  ONE  in  the  combat 
system  organisation  knows  the  complete  status  of  the  combat  system 
to  advise  the  Commanding  Officer  and  TAO  of  remaining  capability. 
The  most  serious  deficiency  is  that  there  is  no  practical  way  for 
Command  to  set  priorities  for  the  reconfiguration  and  restoral  of 
the  combat  system  to  engage  the  most  threatening  targets. 


BATTLE  ORGANIZATION 


3.364 


Alternate  Combat  System  Oroanitation 


The  deficiencies 
discussed  above  are 
being  resolved  aboard 
selected  ships  today  as 
indicated  in  figure  5. 

There  are  two  primary 
benefits  to  this 
organisation:  (l)the  TAO 
and  warfare  officers 
concentrate  of  tactical 
use  of  weapons  systems, 
and(2)  a  single  decision 
maker  prioritises  the 
reconfiguration  and 
restoral  of  the  entire 
combat  to  meet  threats. 

The  centralised 
combat  system  damage 
decision  making  is  the 
functional  equivalent  of 
the  DCA.  With 

centralised  decision 
making,  more  suitable 
facilities  and  decision 
aids  can  be  (and  are) 
provided.  The  facility 
is  commonly  called 
Combat  System 
Maintenance  Central 
(CSMC),  although  the 
same  capabilities  and 
communications  could  be  established  within  the  existing  Repair  8 
(combat  system  repair)  organisation. 

Crucial  to  setting  priorities  for  combat  system  restoral  after 
battle  damage  is  the  complete  understanding  of  the  threat  as  seen 
by  Command/TAO.  This  is  accomplished  within  the  organisation  shown 
in  figure  5  by  the  Combat  System  Resource  Officer  (CSRO)  standing 
in  the  vicinity  of  Command/TAO  in  CIC.  The  CSRO  is  supported  by 
the  CSMC  organisation  and  its  decision  aids  physically  located 
elsewhere  in  the  ship. 

Within  the  CSMC  are  dedicated  maintenance  and  repair 
communications  throughout  the  combat  system  that  do  not  compete 
with  tactical  communications.  Further,  the  CSMC  maintains  not  only 
a  combat  system  plot,  but  a  set  of  vital  systems,  vital  spaces,  and 


ALTERNATE  COMBAT 

SYSTEM 

SEPARATES  OPERATIONS  &  REPAIR 

COfTAO 
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CIC 
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OFFICER 

WARFARE  OPERATORS 
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SURMCE 
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damage  plots  equivalent  to  those  maintained  by  the  OCA. 

5.  SYSTEM  /  EQUIPMENT  SURVIVABILITY 

5.1  Hardening  f Shock.  Firel 

The  common  denominator  of  all  high  explosives  is  shock.  If 
the  combat  system,  vital  systems  and  equipments,  propulsion  and 
electrical,  and  damage  control  systems  are  to  be  of  any  use  after 
battle  damage,  they  must  be  selectively  shock  hardened  up  to  a 
predetermined  set  of  thresholds  for  continued  performance  after 
survivable  damage.  The  design  for  survival  should  address  required 
residual  capability  required  after  both  underwater  burst  shock  and 
air  burst  shock. 

Shock  hardening  of  machinery  such  as  engines  and  generators 
is  more  easily  recognized  than  that  of  antennas,  wave  guides,  and 
chill  water  piping.  However,  if  the  ship  is  to  fight  hurt,  clearly 
defined  hardening  criteria  for  major  equipment  groups  within  the 
combat  system  must  specify  which  components  are  expected  to  fail 
and  define  the  alternate  routing  and  dependency  paths. 

Fire  "Hardening”  as  used  in  this  paper  is  the  time  related 
resistance  of  vital  equipments  and  systems  to  flame  and  high 
temperature.  Data  and  voice  communications  together  with 
electrical  power  distribution  are  prime  examples  of  the  need  for 
fire  hardening.  Various  fire  resistant  cable  conductors  and 
coatings  are  readily  available  for  use  aboard  warships.  Their  use 
should  be  focused  on  vital  circuits  and  data  systems  essential  to 
post-hit  firepower  and  survival.  The  value  added  of  fire  hardening 
is  the  lengthening  of  circuit  and  system  use  from  3-5  minutes  to 
20-60  minutes  when  exposed  to  flame. 

The  time  gained  from  extending  the  use  of  fire  hardened 
circuits/systems  is  during  the  initial  minutes  after  the  occurrence 
of  damage,  which  is  the  most  critical.  Both  the  combat  system  and 
damage  control  organizations  will  benefit.  Further,  by  retaining 
the  vital  capabilities,  the  damage  may  be  rapidly  contained  and 
controlled  such  that  the  hardened  vital  circuits/systems  will  not 
be  disrupted  for  the  remainder  of  the  ships  transit. 

5.2  Separation/Redundancv 

Physical  separation  of  vital  spaces,  systems,  equipments,  and 
connectivity  is  essential  to  battle  damage  survival.  Destroyers, 
Frigates,  and  Cruisers  in  the  4000-9000  ton  displacement  range  will 
be  penetrated  by  the  weapons  and  the  high  explosive/shrapnel 
effects  will  cover  a  predictable  interior  volume  of  the  ship.  Air 
bursts  and  underwater  bursts  also  have  predictable  effects.  Since 
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the  systems/equipments  within  the  lethality  range  of  the  weapons 
will  be  destroyed,  the  only  alternative  is  maximum  feasible 
physical  separation  of  redundant  components. 

Duplication  of  separated  vital  systems/equipments  is  essential 
to  fighting  hurt.  Redundant  components  and  paths  must  be 
physically  separated  to  reasonably  assure  alternate  paths  for 
reconfiguration  after  damage. 

In  many  cases,  ships  today  have  redundant  systems  that  are 
virtually  collocated  (separation  of  a  few  feet  or  less),  primary 
and  alternate  power  supplies  only  available  from  one  power  panel 
or  both  power  panels  located  in  the  same  space,  chill  and  cooling 
water  systems  that  do  not  have  sufficient  bulkhead  cutouts  allowing 
casualty  reconfiguration  due  to  rupture. 

The  effect  of  redundancy  on  post  hit  mission  capability  is 
well  illustrated  by  a  ship  having  only  one  radio  room.  A  hit  in 
that  space  can  eliminate  tactical  communications  with  the  dispersed 
convoy  or  escorts  discussed  in  section  2.1.  An  emergency  radio 
communications  capability  is  essential  today  and  in  the  future  for 
the  same  reasons  it  was  standard  practice  during  World  War  2. 

_ Reconfiguration  After  Battle  Damage 

After  sustaining  battle  damage,  the  only  reasonable  method  of 
reestablishing  ship  capability  is  to  reconfigure  around  destroyed 
or  damaged  systems/equipments.  In  high  threat  environments,  there 
is  no  time  available  to  repair.  The  ship  must  be  rapidly 
reconfigured;  manually,  mechanically,  and/or  electronically,  to 
restore  surviving  capability.  It  is  here,  under  extremely  adverse 
conditions,  that  people  within  the  Battle  Organisation  discussed 
in  section  4  will  fight  and  save  the  ship  using  the  tools  that  are 
provided  them. 

6.  TRAINING  TO  SURVIVE 

Fighting  Hurt  or  Combat  System  Damage  Control,  is  the  ships’ 
crew  using  the  systems,  equipments,  and  procedures  provided  them 
for  the  rapid  recovery  of  the  conjaat  system  by  reconfiguration 
after  battle  damage.  Training  for  battle  damage  requires  voice  and 
data  communications  and  informed  decision  making  throughout  the 
battle  organization  shown  in  figure  3  and  in  particular  within  the 
combat  system  organization  shown  in  figure  5. 

The  training  must  emphasize  the  fact  that  the  post-hit  threat 
will  be  more  intense  as  discussed  in  section  2.1. 
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_ iMLiaina.  RgaliM 

Figure  €  Illustrates  the 
requirement  to  realistically 
expose  the  total  ship  battle 
organisation  to  the  expected 
threat  for  their  area  of 
operations.  By  exposing  the 
crew  to  the  effects  of  self 
defense  weapons  detonating  an 
incoming  missile,  the  effects 
of  anti-shipping  missiles 
detonating  within  the  ship,  and 
torpedoes/mines  exploding  at  the 
extremities  of  the  ship,  the 
crew  gains  knowledge  of  their 
ship  and  confidence  in  their 
ability  to  "handle"  actual 
damage. 

Threat  and  damage  realism  is  essential.  This  can  be  obtained 
from  each  navies  estimates  of  weapons  effects  for  their  area  of 
operation  and  applied  to  the  specific  configuration  of  the  ship 
undergoing  training.  This  can  be  done  cither  manually  or  by  use 
of  computer  models  or  both.  Once  the  threat  and  weapon  effects  are 
determined,  the  actual  damage  expectancy  is  applied  to  ships 
drawings  and  verified  by  observation  aboard  the  actual  ship 
undergoing  training.  The  training  "battle  problems”  are  then 
scripted  in  detail  for  the  ship. 

The  training  must  emphasize  SORVIVABLE  battle  damage  while 
sustaining  the  threat  to  the  ship.  Experience  has  shown  that  only 
the  early  portion  of  the  scenario  up  to  the  initial  hit  can  be 
"scripted"  in  detail.  The  ships'  crew  must  be  allowed  innovative 
responses.  Additional  threats  must  be  disclosed  and  the  ship 
required  to  successfully  engage  them.  If  the  combat  system  fails 
to  successfully  engage  incoming  weapons,  another  "hit"  must  occur. 
In  general,  there  is  no  UNIQUE  solution  to  the  problem.  Thus,  the 
training  team  conducting  training  must  be  capable  of  real  time 
revisions  to  the  battle  problem.  The  most  versatile  method  for 
training  team  response  has  been  found  to  be  VHF  voice  radio  at  the 
4-5  watt  level  of  power. 

ixil _ Design  Benefits 

One  of  the  greatest  benefits  of  realistic  training,  is  that 
the  manual  actions  in  fact  prescribe  a  design  and  control 
algorithm.  The  innovation  and  ingenuity  of  a  ships  crew  provides 
invaluable  insight  into  survivability  of  design  and  past  design 
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flaws.  Capitalizing  on  this  potential  requires  a  close  working 
relationship  between  the  design  community  and  the  operating  forces. 
If  viewed  in  the  context  of  **The  Manual  Implementation  of  the 
Future  Automated  System",  shipboard  survivability  training  can  not 
only  assist  in  design  innovation,  but  serve  to  validate  new 
doctrine,  procedures,  control  position  organisational  requirements, 
display  and  decision  requirements,  and  control  "algorithms”. 

7 .  PAYOFF 

The  payoff,  illustrated  in  figure  7,  is  improved  combat  system 
survivability.  The  probability  of  kill,  Pk,  of  the  combat  system 
is  shown  decreasing  from  current 
firepower  kill  levels  to  that  of 
mobility  and  hull  levels.  Ship 
and  system/ equipment  design 
ultimately  determine 
survivability. 

lU _ Training 

Training  has  proven 
effective  in  restoring  the 
combat  system  to  engage  threats 
after  sustaPhing  simulated 
battle  damage.  Host 

importantly.  Command  decision 
making  is  significantly  enhanced 
and  thus  the  ability  of  Command 
to  set  priorities. 

Prior  to  training,  the 
various  elements  of  the  Battle  Organization  shown  in  figure  3 
focused  on  their  own  areas  of  "doctrinal”  responsibility.  In 
short,  they  did  not  "communicate"  at  the  total  ship  survivability 
level.  With  training,  ships  achieved  a  total  ship  perspective  and 
were  able  to  rapidly  restore  not  only  combat  system  capability,  but 
vital  systems  essential  to  damage  control,  propulsion  and 
electrical  control  throughout  the  ship. 

Ii2 — &Ystem/Equiproent  Survivable  Design 

Training  can  only  enable  the  crew  to  effectively  use  what  is 
provided  by  the  designero.  Significant  further  increases  in 
survivability  can  be  achieved  with  "total  ship  system  engineered" 
hardening,  separation,  and  redundancy.  With  survivable 
reconfiguration,  the  potential  exists  to  exploit  numerous  new  and 
future  weapon  systems  in  a  casualty  mode  of  operation  not  requiring 
the  use  of  vulnerable  own  ship  radars. 
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8 .  CONCLUSION 

Post-hit  firepower  having  the  capability  and  reaction  time  to 
meet  the  requirements  of  the  operational  commander  can  be  achieved 
if  the  combat  system  and  its  supporting  vital  systems  are  designed 
for  damage  reconfiguration. 

Over  the  near  term,  significant  improvements  can  be  made  with 
existing  assets  through  realistic  total  ship  training  and 
modifications  to  ships'  doctrine. 

In  the  long  term,  improvements  in  survivable  design  of  systems 
and  equipments  may  well  extend  combat  system  survivability  to  that 
of  mobility  and  even  beyond  to  that  of  the  hull  (depending  on 
ships'  weapons).  Equal  benefits  can  be  achieved  to  propulsion  and 
electrical  systems  as  well  as  damage  control  systems  through  the 
application  of  this  discipline.  A  close  working  relationship 
between  the  design  community  and  the  operating  forces  can 
capitalize  on  the  "manual  implementation  of  the  future  automated 
system".  This  manual  implementation  will  provide  a  proven 
foundation  for  the  "control  algorithm"  of  the  future  automated 
survivable  control  system  and  its  total  ship  resource  display  and 
decision  requirements. 
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THE  IMPLBMENTATKMI  OP  THE  SHIP'S  POSmOH 
CONTROL  SYSTEM  FOR  THE  ROYAL  NAVY  SINGLE  ROLE  HINEHUHTER 

by  A  H  Burt 

Vosper  Thomycroft  (UR)  Liaited 


1.  ABSTRACT 

This  paper  describes  the  processes  involved  in  the  production  of  the 
Single  Role  Hinehunter,  Ship  Position  Control  System  (SPCS).  The  design, 
test,  and  trials  periods  are  covered,  the  processes  involved  are  explained 
and  the  steps  taken  to  reduce  risk  described. 

The  SPCS  was  developed  by  Vosper  Thomycroft  Controls  for  the  Royal  Navy 
Sandovn  class  of  minehunters. 

2.  mrRODUCTION 

Vosper  Thomycroft  Controls  (VTC)  is  part  of  the  Systems  Group  of  Vosper 
Thomycroft  (UK)  Ltd  and  is  primarily  involved  in  the  design  and  manufacture 
of  control  systems  for  Naval  vessels. 

The  SPCS  was  designed  for  use  upon  the  Sandovn  class  of  minehunters  for 
the  Royal  Navy.  Its  purpose  is  to  automatically  control  the  vessel  during 
minehunting  operations,  and  to  provide  manual  joystick  and  autopilot  control 
functions. 

The  vessel  is  equipped  with  Voitb  Schneider  Propulsors  (VSP)  that 
provide  controllable  vectored  thrust,  and  a  bow  thruster.  The  vessel  uses 
twin  diesel  engines  for  non  minehunting  operations  and  electric  slow  speed 
drives  for  minehunting. 

This  paper  covers  the  techniques  used  to  implement  the  design  and  the 
steps  taken  to  simplify  the  tasks  of  testing,  setting  to  work  and  sea  trials. 

The  system  was  designed  to  meet  a  Naval  staff  requirement  and  was 
required  to  provide  several  different  operational  modes.  The  requirement  was 
to  produce  a  simple  and  easy  to  use  facility  to  control  the  vessel  during 
minehunting  operations  within  set  accuracy  targets.  This  was  intended  to 
reduce  operator  fatigue  and  to  enable  accurate  track  following  over  an 
extended  period  and  for  a  wide  range  of  environmental  conditions. 

2.1  Manual  Joystick 

The  system  was  required  to  provide  a  manual  joystick  mode,  where  a  three 
axis  joystick  is  used  to  control  vectoring  of  the  vessel  thrusters.  The 
joystick  is  fitted  to  the  Quarter  Masters  Console  (OMC),  and  a  portable 
version  can  be  connected  at  various  positions  around  the  vessel.  Hover  mode 
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can  be  selected  by  operation  of  a  pushbutton  adjacent  to  the  joystick.  This 
hovers  the  vessel  at  that  physical  location  until  the  pushbutton  is  operated 
again  or  another  mode  selected. 

This  node  will  be  used  when  berthing  the  vessel  or  when  recovering  and 
deploying  the  remote  vehicle. 

2.2  Track  Keeping 

Track  keeping  is  the  node  used  for  nlnehunting  when  following  a  search 
pattern.  The  Nine  Warfare  Officer  (MVO)  sets  a  plan  to  be  followed  into  the 
Action  Information  Organisation  (AIO)  and  the  coordinates  of  the  required 
waypoints  of  the  track  are  then  transmitted  to  the  SPCS  via  the  Weapon  System 
Data  Bus  (WSDB).  The  SPCS  then  interprets  these  waypoints  as  a  command  to 
track  keep,  and  indicates  to  the  Quarter  Master  that  the  request  to  track 
keep  has  been  received.  The  vessel  is  then  automatically  m2moeuvred  along 
the  track  between  waypoints.  Ship  speed  is  also  controlled  by  the  Mine 
Warfare  Officer  and  sent  along  the  data  bus  with  the  waypoint  data. 

This  mode  is  used  for  minehunting  and  classification  operations.  As  a 
waypoint  is  passed  the  AIO  updates  the  plan  to  ensure  that  the  SPCS  always 
has  three  waypoints  In  its  memory;  thus  enabling  the  SPCS  to  automatically 
follow  a  tight  circular  path. 

2.3  Hover 


When  the  AIO  sends  only  one  waypoint  or  the  last  of  a  series  of 
waypoints  is  reached  the  SPCS  will  automatically  select  Hover  mode. 

The  SRHH  is  equipped  with  a  small  bow  thruster  that  is  adequate  for  all 
normal  berthing  operations  of  the  vessel,  but  does  not  have  sufficient  power 
for  hovering  using  traditional  dynamic  positioning  techniques  at  all 
environments  encountered  during  minehunting.  In  order  to  overcome  this 
limitation  three  variants  of  the  hover  mode  were  developed  to  cater  for  the 
range  of  environmental  conditions  that  the  SPCS  has  to  meet. 

Hover  by  Dynamic  Positioning  with  a  command  desired  heading  (Hover  DP 
CDH)  is  used  in  low  environmental  conditions  with  no  restriction  on  the  ships 
heading.  The  CDH  is  set  by  the  Mine  Warfare  Officer  and  is  transmitted  along 
the  Weapon  System  Data  Bus. 

When  operating  in  Hover-DP  mode,  priority  is  given  to  maintaining 
heading.  The  system  calculates  Northing  and  Easting  position  errors  from  the 
Hover  point  and  the  ship  position.  The  Reading  error  is  calculated  from  the 
desired  Heading  and  the  Ship  Heading.  The  system  takes  the  error  information 
and  processes  it  to  produce  pitch  setting  demands  to  the  VSPs  and  speed 
demands  to  the  BT  in  order  to  keep  the  ship  at  its  Hoverpoint. 

Hover  by  Dynamic  positioning  with  a  favourable  heading  (Hover  DP  FH)  is 
used  in  higher  environments  than  DP  CDH.  The  favourable  heading  is 
determined  by  the  SPCS  as  that  which  will  minimise  the  effects  of  wind  and 
tide  on  the  vessel,  this  heading  is  termed  the  Favourable  Heading.  It  is 
calculated  by  measuring  the  actual  wind  and  tide,  and  then  using  a  ship  model 
to  predict  the  bow  thruster  usage  at  various  headings  between  wind  and  tide 
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directions.  The  minimum  is  found  by  extrapolating  between  the  sampled 
headings  that  produced  the  lowest  bow  thruster  usage. 

Hover  using  Position  Control  by  Manoeuvring  (Hover  PCM)  is  used  in 
environments  up  to  the  maximum  suitable  for  minehunting.  This  mode  uses  the 
VSP  to  work  against  the  environment  to  maintain  the  required  position. 

When  operating  in  Hover  PCM  the  ship  will  tend  to  move  in  the  desired 
direction  to  correct  any  positional  errors  rather  than  moving  laterally. 
Under  steady  conditions,  the  ship's  heading  is  the  Favourable  Heading. 

2.4  Autopilot 

The  SPCS  implements  a  traditional  Autopilot  function  using  the  same 
hardware  as  for  the  other  automatic  modes.  The  mode  is  selectable  by  the 
Quarter  Master,  and  a  desired  ships  heading  entered.  The  SPCS  then  controls 
the  VSP  lateral  pitch  to  maintain  the  desired  vessel  heading.  VSP 
longitudinal  pitch  is  set  to  full  ahead  and  vessel  speed  is  controlled  by 
adjustment  of  the  main  engine  speed. 

The  desired  heading  is  adjusted  at  the  QMC  by  means  of  increase  and 
decrease  pushbuttons  until  the  desired  heading  is  displayed  on  the  plasma 
display,  the  operator  can  then  enter  the  new  heading  into  the  controller. 

A  yev  limit  and  the  usable  steering  pitch  are  also  operator  adjustable. 
The  autopilot  is  based  on  a  three  term  controller  with  a  wind  feed  forward 
term. 


2.5  Minehunting  Under  SPCS  Control 


WP2 


WIND 


WP1 


Figure  1  shows  a  typical  minehunting  exercise,  and  demonstrates  how  the 
automatic  modes  are  used.  The  AIO  transmits  a  pattern  of  waypoints,  tfPl,  WP2 
and  WP3  to  the  SPCS  and  the  system  will  select  track  keeping  node.  When  an 
artefact  is  detected  (point  A)  between  WP3  and  WP4,  the  AIO  will  send  a  new 
plan  of  WPlOOl  and  WP1002.  The  vessel  will  hover  at  WP1002  while 
classification  takes  place.  Following  further  periods  of  classification  at 
VP1003  and  VP1004,  the  vessel  will  retreat  to  UP1005  for  disposal. 
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All  of  the  above  operations  will  be  carried  out  under  automatic  control 
of  the  SPCS.  The  Quarter  Masters  only  duty  is  to  monitor  the  vessel 
performance  and  to  ensure  that  the  selected  hover  mode  is  the  most  suitable 
for  the  actual  environment. 


3.  SPCS  DBSIGM 

There  are  three  main  sections  to  the  SPCS  design: 

The  hardware  design 
The  software  design 
The  control  algorithm  design 
3.1  The  Hardware 

The  system  is  implemented  using  processors  and  interface  cards  from  the 
VTC  range  of  D86  PCBs,  as  already  used  on  various  other  RN  vessels;  the  T23 
frigate,  the  T2400  submarine,  and  the  Trident  submarine;  as  well  as  other 
foreign  naval  vessels. 

Special  precautions  had  to  be  taken  to  protect  the  electronics  from  the 
harsh  EMC  environment  encountered  on  board  Glass  Reinforced  Plastic  (GRP) 
vessels.  This  Included  fitting  any  vulnerable  electronics  within  double 
screened  enclosures,  and  the  filtering  of  supply  and  signal  cables. 


Figure  2  -  System  Interfaces  with  Propulsion  Machinery 
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The  SPCS  system  is  housed  within  the  Quarter  Masters  Console  (QMC)  and 
interfaces  with  the  Direct  Control  System  (DCS)  also  housed  in  the  QMC  and 
supplied  by  VTC.  The  QMC  is  mounted  on  the  bridge.  Figure  2  shows  the 
arrangement  and  the  interfaces  with  the  Voith  Schneider  propulsors. 

a.  SPCS  -  The  SPCS  consists  of  one  rack  of  electronics  with  all 
necessary  power  supplies,  interfaces,  and  Htm  Machine  Interfaces  (MHIs) 
mounted  in  a  console  that  forms  half  of  the  Quarter  Masters  console. 

The  MMI  comprises  a  plasma  display,  a  fallback  display  and  all  necessary 
pushbutton  switches  and  indicators.  The  plasma  display  has  a  dedicated  page 
for  each  mode  that  gives  all  the  relevant  data  for  that  mode.  Figure  3  shows 
the  display  for  track  keeping  mode.  Three  status  pages  are  also  available  to 
give  further  useful  parameters. 
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Figure  3  -  Typical  Plasma  Display  -  Track  Keeping 
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The  fallback  display  provides  sufficient  information  to  enable  the 
system  to  function  correctly  on  failure  of  the  primary  plasma  display,  and 
consists  of  arrays  of  indicating  lamps  shoving  across  track  error,  along 
track  error,  and  heading  error. 

As  most  of  the  SPCS  modes  are  fully  automatic,  the  primary  function  of 
the  MHI  is  surveillance,  and  alarms  or  warnings  will  be  raised  should  any 
system  or  Interface  problems  arise,  as  veil  as  providing  all  relevant  vessel 
and  environmental  data  via  the  plasma  display. 

b.  Direct  Control  System  -  The  DCS  is  the  normal  method  of  controlling 
the  vessel  and  provides  independent  longitudinal,  and  lateral  control  of  the 
Volth  Schneider  propulsor  pitch  as  well  as  bov  thruster  control. 

The  VSP  pitch  is  controlled  by  hand  levers  and  a  helmvheel  providing 
demands  to  dedicated  electronics  that  implement  closed  loop  control  of  the 
VSP  actuators.  The  DCS  interfaces  with  the  propulsion  systems  are  shown  in 
Figure  2. 

Each  control  loop  is  independent  and  was  designed  to  achieve  a  high 
reliability.  This  was  achieved  by  minimising  the  component  count,  component 
screening  and  the  elimination  of  single  point  failures. 

The  Inclusion  of  the  high  reliability  control  system  was  to  ensure  that 
vessel  safety  was  not  compromised  by  common  mode  failures.  The  transfer  from 
SPCS  control  to  DCS  control  can  be  achieved  by  the  operation  of  a  single  mode 
select  switch  on  the  QHC. 

The  SPCS  controls  the  vessel  by  the  use  of  isolated  analogue  inputs  in 
the  DCS,  so  any  SPCS  failures  will  not  affect  DCS  availability. 

The  main  engine  speed  control  and  hence  VSP  shaft  control  also  forms 
part  of  the  DCS  and  is  independent  of  the  SPCS.  Each  engine  speed  is 
controllable  by  an  array  of  pushbuttons  that  control  the  governor  setting  by 
means  of  a  stepper  motor.  Setting  the  governor  to  minimum  when  the  slow  speed 
electric  motors  are  running  causes  the  automatic  changeover  of  the  Self 
Synchronising  and  Shifting  (SSS)  clutches. 

c.  toterfaces  -  Figure  4  shows  the  interfaces  with  the  other  ships 
systems  and  navigation  aids.  All  positional  data  is  received  via  the  VSDB, 
as  well  as  sonar  positional  data  and  system  time. 

The  SPCS  has  been  designed  to  function  correctly  with  a  variety  of 
navigational  aids,  and  the  X  Y  coordinates  are  received  from  the  AIO  via  the 
VSDB.  Racal  Hyperfix  is  the  normal  navaid  used,  due  to  its  extensive 
coverage  of  UK  coastal  waters. 

Ships  heading,  and  wind  direction  are  received  via  synchro  interfaces. 
Vlnd  speed  is  received  via  an  analogue  signal. 
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Figure  4  -  SPCS/Navaid  Interfaces 


d.  Cottelation  Blectrowagnetic  Spe^  log  -  Surge  euid  sway  ground  and 
water  speed  are  received  via  an  ftS42z  link  directly  from  the  Correlation 
electromagnetic  speed  (CHS)  log.  This  system  has  been  developed  in  a 
military  version  by  VTC  for  the  SRKH.  The  system  provides  an  accurate 
measurement  of  surge  and  sway  ground  speed  by  using  ground  tracking 
techniques.  The  CHS  log  also  incorporates  a  electromagnetic  log  that 
provides  alongships  and  athvartships  water  speed. 

3.2  The  Software 

The  application  software  was  implemented  using  tried  and  tested 
standard  VTC  I/O  modules.  This  use  of  proven  software  reduced  risk  and 
simplified  the  task  of  integration  ano  test.  The  code  is  mainly  written  in 
CORAL  60  with  assembler  used  where  dictated  by  speed,  and  was  developed 
within  a  Context  environment. 
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Structured  Analysis  and  Design  techniques  were  used  in  the  development 
of  the  system  software.  Rigorous  testing  of  software  modules  was  employed  to 
reduce  the  integration  time. 

The  application  specific  software  consisted  of  code  to  handle  control 
mode  transitions;  to  handle  the  HMI  and  to  call  the  relevant  control 
algorithms.  Functions  such  as  the  database  management,  I/O  handling,  and 
comms  handling  all  used  standard  VTC  modules. 

The  software  incorporates  extensive  diagnostics  and  failure  detection  to 
simplify  and  speed  up  fault  iuentification  and  repair. 

3.3  The  Control  Algcriliias 


The  development  of  the  control  algorithms  was  carried  out  by  running  a 
ship  simulation  on  a  uVax  computer.  The  algorithms  vent  through  many  design 
stages  and  took  many  forms  before  the  final  designs  were  settled  upon. 

Different  control  techniques  for  the  algorithm  designs  were  tested  by 
coding  them  and  then  cunning  them  against  the  simulation.  Stable  hover  and 
track  keeping  performance  was  then  observed  as  well  as  performance  in 
transient  situations  such  as  veering  wind  and  tide  conditions  or  turning  at 
waypoints. 

The  use  of  Linear  Kalman  filters  was  investigated  and  while  this  offered 
good  performance  in  linear  or  stable  conditions,  gave  unacceptable 
performance  in  non-linear  situations  such  as  manoeuvring. 

Eventually  conventional  three  term  controllers  were  found  to  be  the  most 
suitable  robust  option.  After  initial  testing  of  the  designs,  the  algorithms 
were  coded  in  coral  for  inclusion  into  the  system  software.  The  designs  were 
also  included  in  a  SPCS  model  within  the  simulation,  the  simulation  was  than 
used  to  evaluate  the  algorithm  performance  over  the  full  range  of 
environments  and  conditions. 

Separate  algorithms  were  developed  for  each  operational  mode;  Autopilot, 
Track  keeping.  Hover  DP  and  PCM,  plan  interrupt  and  ship  emergency  halt;  as 
well  as  for  the  favourable  heading  calculation.  The  favourable  heading 
module  is  used  to  calculate  the  best  heading  for  hovering  for  the 
environment.  This  is  achieved  by  calculating  the  Hydro,  Aero  and  Sonar 
forces  on  the  vessel  for  a  range  of  headings  between  the  actual  wind  and 
tide,  and  then  calculating  the  required  use  of  the  bow  thruster  for  that 
heading.  The  heading  that  gives  the  minimum  use  of  the  bow  thruster  is  the 
favourable  heading. 

The  algorithm  gains  and  limits  were  then  tuned  and  adjusted  as  the 
result  of  extensive  simulation  work. 

Once  the  algorithm  gains  had  been  finalised,  the  system  was  subject  to  a 
full  stability  analysis.  This  involved  analysis  of  the  SRMH  system  without 
any  controller  and  then  adding  the  analysis  for  each  controller.  The 
analysis  was  carried  out  by  examining  the  response  of  a  linearised  model  of 
the  system  to  small  control  inputs  and  disturbances.  The  results  of  the 
linear  model  analysis  were  compared  with  results  from  the  non-linear  model  to 
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ensure  accuracy  of  the  linear  model.  The  linear  model  was  then  exercised 
over  a  wider  range  of  environments  in  order  to  find  any  areas  of  instability. 
The  stability  analysis  indicated  that  the  SPCS  would  be  stable  across  all 
required  operating  scenarios. 

a.  Fallback  Modes  -  While  the  vessel  will  normally  have  all  the 
required  thrusters  available  for  minehunting;  the  SPCS  has  been  designed  to 
operate  with  only  one  Voith  Schneider  Propulsor  functional.  This  means  that 
in  most  environments  the  SPCS  can  function  with  little  or  no  loss  of 
performance  with  only  one  shaft  available. 

The  SPCS  can  also  function  with  the  shafts  at  different  speeds  again 
with  little  effect  on  performance.  This  flexibility  means  that  the  SPCS  can 
make  maximum  use  of  the  available  propulsion  prime  movers. 

Various  navaids  can  be  replaced  by  estimated  data  in  the  event  of  navaid 
failure.  Thus  loss  of  non-critical  navaids  will  not  mean  total  loss  of  the 
system. 


b.  Molse  Limiting  Algorithms  -  Provision  has  been  made  to  limit  the 
SPCS  usage  of  thrusters  in  order  to  limit  thruster  noise.  The  noise  limiting 
algorithms  will  be  determined  after  noise  ranging  of  the  vessel  and  can  be 
Incorporated  with  no  software  redesign. 

The  algorithms  will  most  likely  limit  the  Bow  Thruster  and  VSP  usage  to 
reduce  the  risk  of  cavitation. 

4.  THB  SIWIIATION 

A  complete  ship  simulation  was  developed  by  VTC  and  included  Bull  and 
Machinery  models  provided  by  the  shipbuilder  and  the  Ministry  of  Defence. 

The  simulation  also  included  models  of  the  SPCS,  CHS  log,  AID  and  VSDB, 
as  well  as  a  full  environmental  model.  The  simulation  was  enhanced  and 
expanded  as  algorithm  design  progressed.  This  included  the  addition  of 
enhanced  graphical  displays  and  monitors  for  the  calculation  of  performance 
figures.  The  Improved  HHI  greatly  reduced  the  task  of  analysis  of  large 
quantities  of  trials  results. 

The  primary  purpose  of  the  simulation  was  to  accurately  model  the  real 
operating  environment  of  the  system  in  order  to  establish  the  system 
functionality  and  to  enable  realistic  testing  of  the  system.  This  was 
carried  out  in  order  to  reduce  the  setting  to  work  time  required  on  board  the 
vessel. 

The  simulation  was  then  used  to  form  the  basis  for  a  system  test 
facility,  where  the  vessel,  the  ship  interfaces,  and  the  environmental 
conditions  were  simulated  in  order  to  functionally  test  the  complete  system. 

The  simulation  was  also  used  to  define  the  effects  of  tuning  the 
algorithms.  Thus  maximum  and  minimum  values  and  the  sensitivity  of  each 
parameter  was  determined  before  sea  trials. 
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Various  failure  modes  of  ships  equipment  were  simulated  in  order  to  test 
the  fallback  systems  within  the  SPCS  and  the  designs'  ability  to  withstand 
degraded  sensor  performance. 

5.  TRIALS  LOGGIHG  PACIUTT 

As  sea  trials  time  was  going  to  be  very  limited  and  due  to  the  dynamic 
nature  of  the  SPCSi  it  was  important  to  make  full  use  of  all  ship  time.  In 
order  to  achieve  this  and  to  ensure  that  any  unexplained  or  transient 
phenomena  were  recorded  a  data  logging  facility  was  developed.  The  main 
functions  of  this  facility  are: 

The  logging  of  internal  SPCS  parameters. 

The  tuning  of  algorithm  gains. 

The  production  of  performance  figures. 

The  facility  was  implemented  using  a  pVAx  computer  connected  via  an 
RS422  link  to  the  SPCS  display  processor.  The  display  processor  was  then 
able  to  access  the  main  SPCS  database  and  supply  the  required  parameters  to 
the  logging  computer.  The  parameters  to  be  logged  can  be  selected  from  the 
logging  computer  and  this  selection  passed  to  the  SPCS,  thus  only  selected 
parameters  are  passed  down  the  data  link. 

Several  parameters  can  also  be  logged  from  the  port  and  starboard 
Machinery  control  and  surveillance  systems. 

The  data  available  to  the  logging  facility  are  algorithm  gains  and 
limits,  -controller  outputs,  filter  and  navaid  data,  as  well  as  SPCS  mode  and 
thruster  Information.  Over  three  hundred  different  parameters  are  available 
for  monitoring  or  tuning,  of  which  any  100  can  be  logged  at  one  time. 

This  facility  is  also  used  during  system  integration  and  test  to  log 
system  parameters  in  order  to  troubleshoot  faults  when  connected  to  a  system 
on  the  test  facility.  The  performance  monitor  is  used  to  provide  performance 
figures  during  factory  acceptance  tests. 

Algorithm  tuning  is  required  to  adjust  the  performance  of  the  algorithms 
on  board  the  vessel  to  give  the  desired  performance.  Thus  the  effect  of 
inaccuracies  in  the  simulation  database  can  be  minimised.  Prior  to  sea 
trials  the  effect  of  algorithm  tuning  was  tested  on  the  simulation.  Maximum 
and  minimum  safe  levels  for  each  gain  were  determined  using  the  simulation. 
Thus  the  tuning  of  algorithms  could  be  undertaken  without  affecting  the 
system  stability. 

Once  a  parameter  has  been  selected  for  display  the  facility  can  log  it 
to  a  disk  file  for  processing  at  a  later  date.  This  data  can  then  be  post 
plotted  to  give  a  permanent  record  of  any  trial  or  manoeuvre.  An  example  of 
the  plotted  data  is  given  in  Figures  5  to  7.  Figure  5  shows  the  vessel  path 
during  the  logging  period.  The  vessel  position  is  plotted  at  regular 
Intervals  to  indicate  the  vessel  heading  and  at  a  scale  that  will  not  obscure 
the  path.  Figures  6  and  7  show  various  SPCS  parameters  throughout  the 
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logging  periodt  thus  enabling  different  parameters  to  be  compared  with  each 
other  at  any  time  during  the  trial. 

The  output  of  each  term  of  each  three  term  controller  can  be  examined  to 
analyse  the  controller  performance  and  give  a  guide  to  any  tuning  required. 

6.  HARBOUR  ACCEPTANCE  TRIALS/LimClMG 

The  Harbour  Acceptance  Vrial  (RAT)  and  linking  trials  to  various  ship 
systems  were  carried  out  during  the  setting  to  vork  period.  The  purpose  of 
these  trials  were  to  prove  the  functionality  of  the  interfaces  to  other  ships 
equipment  and  to  ensure  that  the  SPCS  had  been  correctly  installed  prior  to 
going  to  sea. 

Due  to  the  dynamic  nature  of  the  SPCS  it  vas  not  possible  to  fully  test 
the  system  with  the  vessel  tied  up  alongside  a  harbour  vail. 

7.  PRR  SKA  ACCEPTAHCE  TRIALS 

Prior  to  the  formal  Sea  Acceptance  Trials  (SATs)  a  period  of  setting  to 
vork  and  tuning  at  sea  vas  made  available  and  vas  referred  to  as  the  Pre  SATS 
period.  The  aims  of  this  period  vere  to  test  each  mode  to  ensure  correct 
functionality;  to  gather  data  about  the  real  ship  to  compare  vith  the 
simulation  models;  to  carry  out  tuning  of  the  algorithms  if  required;  to 
dynamically  test  the  system;  and  to  enable  ships  staff  to  familiarise 
themselves  vith  the  system  prior  to  handover. 

The  Pre  SATs  period  vas  split  into  several  sections  as  determined  by  the 
ship  part  4  trial  programme.  The  first  veek  took  place  off  Portland  in 
November  1989,  and  vas  characterised  by  extremes  of  environment.  The  first 
day  vas  absolute  calm  folloved  by  three  days  of  gales.  Bovever  the  trials 
vere  a  success  vith  all  modes  functioned  and  the  logging  system  proven. 

The  autopilot  proved  to  vork  satisfactorily  and  the  manual  Joystick  in 
both  local  and  remote  modes  vas  proved.  Track  keeping  vas  tested  and 
functioned  correctly  despite  the  very  high  vinds;  Hover  testing  vas  more 
limited  as  only  the  PCH  mode  could  be  used  in  the  environment  encountered. 

Figures  5  to  7  shov  the  results  of  a  track  keeping  trial  from  the  Pre 
SATs  period.  The  vessel  follovs  tracks  of  170,  270,345,  and  15  degrees. 
Figure  5  shovs  the  vessel  manoeuvring  around  the  required  track  as  veil  as 
plot  Information.  Figure  6  shovs  various  vessel  parameters  including  vind 
and  tide  speed  and  direction.  Figure  7  shovs  some  of  the  track  keeping 
parameters  that  vere  logged  including  track  speed  and  direction. 

A  fev  minor  interface  problems  vere  discovered  during  this  veek  in  both 
SPCS  and  ships  interfaces  and  these  vere  corrected  prior  to  the  second  veek 
vhen  it  vas  intended  to  fully  test  the  Hover  and  Track  keeping  modes.  These 
modes  have  to  function  correctly  vith  and  vithout  the  hunt  sonar  deployed  and 
these  tests  vere  carried  out  off  Rosyth  in  April  1990. 

One  of  the  objectives  of  the  Pre  SATs  vas  to  gather  as  much  data  as 
possible  regarding  the  system  and  vessel  performance.  Vhen  a  trial  has  been 
conducted  satisfactorily  it  can  then  be  rerun  on  the  simulation  in  order  to 
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validate  the  simulation.  Once  the  simulation  has  been  shovn  to  be  accurate 
or  any  differences  explained;  the  extensive  simulation  results  become  an 
accurate  system  performance  definition,  and  future  operational  problems  or 
changes  can  be  tested  against  the  simulation. 

8.  SKA  ACCEPTANCE  TRIALS 

The  purpose  of  conducting  Sea  Acceptance  Trials  (SATs)  is  to  show  that 
the  system  meets  the  customer  requirements,  and  to  demonstrate  all  modes  of 
operation. 

The  system  will  be  demonstrated  by  VTC  to  the  shipbuilder  and  the 
Ministry  of  Defence  at  the  same  time.  The  total  time  allocated  to  the  trials 
is  four  days  of  sea  time.  Due  to  the  dynamic  nature  of  the  system  and  its 
inter-reaction  with  the  the  environment  testing  will  be  limited  to  that 
achievable  in  a  few  days.  Hence  no  attempt  vill  be  made  to  conduct  trials  in 
different  combinations  of  wind  and  tide,  and  the  simulation  results  vill  be 
used  to  give  more  extensive  results. 

The  SATs  vill  include  demonstrations  of  each  control  mode.  Hinehunting 
modes,  track  keeping  and  hover  vill  be  demonstrated  vith  and  vlthout  the 
sonar  deployed.  Performance  figures  vill  be  calculated  by  the  data  logger 
computer  vith  Independent  checking  of  navaid  accuracy.  The  SATs  are 
scheduled  for  completion  in  April  1990. 

9.  coMCLasrows 


During  system  development  several  areas  have  been  found  vhere 
Improvements  can  be  made  to  enhance  performance  and  it  is  hoped  that  these 
can  be  included  in  the  near  future.  Work  is  also  under-vay  to  look  at 
developing  the  algorithms  for  use  on  other  similar  vessels. 

The  SPCS  has  nov  been  fully  tested  by  the  shipbuilder,  and  has  proved 
its  ruggedness  and  suitability  for  the  harsh  environment  in  vhich  it  vill  be 
required  to  operate. 

The  usefulness  of  extensive  simulation  vork  in  the  design  and  analysis 
stages  of  a  project  such  as  this  has  been  proved.  Without  the  ability  to 
test  algorithm  design  against  a  computer  simulation  the  production  of  a 
vorklng  system  vould  have  been  almost  impossible.  The  total  non-customer 
acceptance  testing  at  sea  for  the  SPCS  system  vas  eleven  days  during  vhich 
the  vessel  was  not  alvays  exclusively  available  for  VTC  use. 

The  inclusion  of  a  fully  automatic  ship  control  system  should  greatly 
improve  the  overall  minehunting  effectiveness  of  the  vessel;  due  to  good 
predictable  performance  over  a  vide  range  of  environments  vith  minimal 
operator  Involvement. 
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1.  ABSTRACT 

This  paper  describes  the  design,  development  and 
implementation  of  a  multivariable  optimal  control  system  for 
the  guidance  of  vessels  in  confined  waters.  The  work  is 
part  of  an  overall  strategic  programme  to  optimally  guide  a 
ship  from  port  approaches  at  the  start  to  port  approaches  at 
the  completion  of  a  voyage.  During  the  pilotage  phase,  the 
cost  function  is  weighted  to  minimise  track,  course  and 
speed  errors,  whilst  in  the  oceanic  phase,  it  is  weighted  to 
Minimise  fuel  and  time. 

A  non-linear,  discrete,  time-varying  ship  mathematical 
model,  validated  with  results  from  sea  trials  is  embedded 
within  an  optimal  filter  which  accepts  raw  data  from  the 
vessel's  navigation  instruments  and  passes  best  estimates  to 
the  optimal  controller. 

Results  from  simulation,  model  testing  and  full-scale 
sea  trials  are  presented  for  manoeuvring  modes,  together 
with  possible  control  strategies  for  open-seaway  operation. 

2 .  IMTSOPDCTZOM 

Automatic  guidance  of  ships  has  its  origin  near  the 
beginning  of  this  century,  following  the  invention  of  the 
gyrocompass.  Sperry  (1)  discussed  the  problems  of  automatic 
steering  in  1922  and  in  the  same  year  Minorsky  (2)  presented 
the  basic  theory  for  directional  stability  of  automatically 
steered  ships.  Ten  years  later  over  four  hundred  of 
Sperry's  autopilots  had  been  installed  on  merchant  ships 
throughout  the  world.  Traditionally,  ship  autopilots  are 
single- input,  single-output  systems  designed  to  control  the 
vessel's  heading.  Since  proportional  control  tends  to 
produce  oscillatory  response,  and  integral  control  is 
required  to  reduce  errors  due  to  environmental  disturbances 
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such  as  wind  and  waves,  conventional  autopilots  use  a 
proportional,  integral  and  derivative  (PID)  control  law  as 
described  by  Bech  (3) .  However,  vessel  response  is 
sensitive  to  control  parameter  settings  and  more  recent  ship 
controllers  are  based  upon  the  pioneer  work  of  Honderd  and 
Winkelman  (4)  in  1971  and  Astrom  and  Wittenmark  (5)  in  1973, 
and  employ  adaptive  algorithms  to  Implement  self-tuning 
autopilots. 

The  fundamental  problem  with  existing  ship  autopilot 
control  systems  is  that  they  are  single  dimensional, 
controlling  one  parameter  only,  whereas  by  its  very  nature  a 
ship  is  a  multidimensional  system  with  many  Inputs,  and  many 
outputs  that  require  to  be  controlled  simultaneously. 

_  By  the  use  of  multivariable  system  theory  it  is 
possible  to  describe  the  motion  of  a  ship  in  several  degrees 
of  freedom. _  This  enables  the  formulation  of  an  optimal 
control  policy  that  can  view  the  global  problem,  and  so 
minimise  the  errors  in  controlled  variables  according  to 
some  predefined  order  of  priority.  Expressed  in  another 
way,  an  optimal  control  system  will  seek  to  maximise  the 
return  from  the  system  for  a  minimum  cost. 

Stochastic  optimal  control  theory  employs  the 
separation  principle  to  reduce  a  given  optimisation  problem 
into  two  subsequent  problems  whose  solutions  are  known, 
namely  an  optimal  filter  in  cascade  with  a  deterministic 
controller.  If  a  multivariable  ship  model  has  been 
identified,  then  the  ship  guidance  problem  can  be  expressed 
as  shown  in  Figure  1. 


desired  state  r  ^ 


Figure  1.  The  Ship  Guidance  Problem 
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3.  SHIP  MATHEMATICAL  MODEL 

The  Euler  equations  of  motion  in  surge,  sway  and  yaw 
are  required  for  manoeuvring  in  confined  waters  (6) ,  whereas 
the  equations  of  pitch  and  heave  are  important  in  an  open 
seaway  (7) .  Since  roll  does  not  contribute  significantly  to 
added  resistance,  it  has  not  been  included.  The  equations 
for  a  five  degree  of  freedom  model  are  given  below: 

Surge  Equation 


mu  +  mqw  —  mrv  =  ^u  ^uu^^  ^uuu^^ 

+  X„r2  +  +  X„^^  +  Xunun^  +  XnnnA2  +  XyaUg  + 

+  (1) 

Sway  Equation 

mv  +  mur  =  V^v  +  Yy(v+VQ)  +  yj.r  +  Yj.r  +  Xyjyjn2^  +  Yy^v^ 

^  ^nm«i**^A  ^^A  ^«vv^A''^  ^va'''a  (2) 

Heave  Equation 


m(w-qu)  =  Z^w  +  Zy,w  +  Z^z  +  Z^tf  +  Zgq  +  Z^^  +  Z^fa  (3) 

Yaw  Equation 

I^r  =  N^v  +  Ny(v+Vg)  +N^r  +  Nnnn2^  ^  Nyw''^ 

+  Nj;.yyrv2  +  Nj,jjjn2^6;^  +  Nj,n«  ii^^A^^A  +  ^«vv*A''^  ^^va'^a  ('*) 

Pitch  Equation 


lyq  =  M<jq  +  Mqq  +  +  M^z  +  M^w  +  HgP  + 


(5) 
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The  fin  dynamics  are  not  taken  into  account.  Equations 
(1)  to  (7)  can  be  arranged  in  the  state  matrix  vector  form; 

x(t)  =  P(t)x(t)  +  Gc(t)u(t)  +  6D(t)w(t)  (8) 

where , 

hA  X  u  y  V  0  r  z  w  fl  q)  (9) 

=  (^D  ”d  P)  (10) 

=  (Uc  Uc  Ug  Vg  fa)  (11) 

The  corresponding  discrete  solution  is: 

X({K+1)T)  =  A(T,KT)X(KT)  +  B(T,KT)U{KT) 

+  C(T,KT)W(KT)  (12) 

4 .  CONTROL  LAW 


The  quadratic  performance  criterion  for  an  optimal 
tracking  system  is: 


J  = 


■ti 

{(x-r)l'  Q  (x-r)  +  R  u)  dt 

>  ■^0 


(13) 
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Q  and  R  are  diagonal  matrices  and  the  values  of  the 
individual  elements  reflect  the  importance  of  the  parameters 
being  controlled. 

In  a  track- keeping  situation  for  example,  elements  ^55 
and  qgg  (that  relate  to  y  and  v)  are  required  to  be  heavily 
weighted  so  that  the  majority  of  the  control  effort  is 
expended  in  reducing  cross-track  error.  When  steaming  in  an 
open  seaway  however,  elements  q44,  qgg  and  q^  U  (that 
relate  to  forward  speed,  heave  and  pitch)  should  be 
emphasised  for  fuel  economy. 

It  can  be  shown  (8)  that  constrained  functional 
minimisation  yields  the  matrix  Riccati  equations; 


W  =  -W  P  -  P'^W  -  Q  +  W  G  R"^  W 


(14) 


from  which  the  optimal  control  law  becomes: 


“opt  = 


(15) 


or, 


“opt  *  B(x~r) 


(16) 


where  the  feedback  matrix  is 


8  =  -R“l  W  (17) 


5 .  COMPUTER  SIMULATION 

5.1  Simulation  in  Port  Approaches 

The  study  vessel  used  in  the  simulation  was  a  150  m 
long  car  ferry  of  displacement  14,400  tonnes.  Linear  and 
non-linear  hydrodynamic  coefficients  were  obtained  from 
towing  tank  tests  on  a  3.4  m  long  model  of  the  ferry, 
conducted  at  the  National  Physical  Laboratories,  Teddington, 
and  values  substituted  into  equations  (1),  (2)  and  (4). 

Figure  2  shows  a  simulated  approach  of  the  ferry  into 
the  Port  of  Plymouth  at  a  forward  speed  of  7.717  m/s  (15 
knots)  with  no  wind  or  tidal  disturbance  effects.  The 
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Figure  2.  High  Speed  Simulated  Passage  Into  Port  of 
Plymouth  with  no  Disturbance  Effects. 
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controller  parameters  are  set  to  provide  the  following 
emphasis: 


a) 

track 

control , 

b) 

course  control. 

c) 

speed 

control . 

As  a  result,  at  each  way-point  the  vessel  pulls  quickly 
onto  the  new  track,  but  in  doing  so  incurs  errors  in  both 
course  and  speed. 

In  Figure  3,  the  vessel  approach  speed  is  5  knots  2.572 
m/s  (5  knots)  and  it  is  being  subjected  to  a  force  8  wind 
and  2  knot  tidal  stream  both  from  a  south-westerly 
direction.  It  can  be  seen  here  that  the  vessel  is  being 
dragged  off  track  although  maximum  control  effort  is  being 
applied.  This  indicates  the  limiting  condition  of  safe 
operation  of  the  control  system. 

_ Simulation  in  a  Seaway 

When  a  vessel  is  moving  in  a  seaway  its  increased 
motion,  particularly  in  pitch  and  heave,  produces  additional 
resistance  and  hence  a  loss  in  forward  speed. 

Figure  4  shows  the  response  of  the  study  vessel  to  a 
Pierson  Moskowitz  sea  spectrum  for  a  significant  wave  height 
of  4.573  m  (15  feet).  As  a  result  of  pitch  and  heave  motion 
the  forward  speed  of  the  vessel  reduces  from  the  initial 
7.717  m/s  calm  water  value  to  5.8  m/s. 

If  bow  and  stern  control  fins  are  fitted  to  the  vessel, 
it  is  possible  to  adjust  the  control  action  by  computing  a 
feedback  matrix  with  reduced  emphasis  on  track  control,  but 
increased  weighting  on  pitch  and  heave.  Figure  5 
illustrates  the  effect  of  such  control  action  for  the  same 
sea-state,  where  it  can  be  seen  that  the  pitch  and  heave  are 
significantly  reduced  and  here  the  final  forward  speed  is 
6.75  m/s.  This  represents  a  fuel  saving  of  24.7%  based  on 
power  requirements. 
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Figure  3.  Low  Speed  Simulated  Passage  into  Port  of 
Plymouth  in  the  Presence  of  Wind  and  Tide 
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Figure  5.  Simulated  Effect  of  Pitch  and  Heave  Control 
on  Forward  Speed. 
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6. 


MODEL  TESTS 


Prior  to  full-scale  sea  trials,  the  guidance  system  was 
tested  on  a  free-sailing  3.4  m  long  car  ferry  model  (the 
same  vessel  that  was  used  to  evaluate  hydrodynamic 
coefficients) . 

The  vessel  was  fitted  with  a  computer  which  had  the 
optimal  control  and  filter  software  installed.  An  inertial 
navigation  system  consisting  of  3  accelerometers,  3  rate- 
gyros  and  one  heading  gyro  was  employed  to  measure  state 
variables.  Main  engines  and  rudder  were  driven  by  servo- 
systems  that  could  be  either  under  computer  or  radio 
control.  Figure  6  shows  a  typical  set  of  raw  measurements 
taken  from  the  instruments. 


O  20  40  60  80  100  110  120 

TIm  (seconds) 

Figure  6.  Raw  Data  taken  from  Inertial  Instruments 
on  Model  Car  Ferry. 

In  Figure  7  the  model  is  placed  initially  5  m  off-track 
and  is  required  (a)  to  lock  onto  the  present  track  and  (b) 
to  lock  onto  a  90  degree  track.  Both  filtered  measurements 
and  simulation  results  are  displayed  and  it  can  be  seen  that 
the  system  anticipates  the  way-point  to  prevent  transient 
overshoot.  Figure  8  shows  unfiltered,  filtered  and 
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Figure  7.  Simulated  and  Filtered  Measured  Track: 

Free-Sailing  Tests  on  Model  Car  Ferry. 
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simulated  measurements  of  course  angle,  Y^w-rate  and  lateral 
speed.  In  the  latter  case,  the  integration  drift 
unfiltered  measurement  can  be  seen. 

7 .  SEA  TRIALS 

The  guidance  system  was  fitted  on  to  an  11  ® 

hulled  vessel  and  tested  in  the  approaches  to  the  Port  of 
Plymouth.  The  mathematical  model  of  the  vessel  wa 
from  a  series  of  manoeuvring  trials. 

The  navigation  instruments  consisted  of 
DQsition  fixing,  log  and  flux-gate  compass. 

Dositional  accuracy  was  monitored  by  Trisponder,  installed 
on  the  vessel  for  hydrographic  surveying  purposes.  All 
measurement  signals  were  sent  to  a  dedicated  microprocessor, 
which  relayed  the  information  to  the  main  guidance  comput  . 
taken 

period  the  optimal  filter  and  control  calculations  tooK 
olace  resulting  in  demanded  rudder  and  engine  speed 
beiS'  cen^eyed  to  the  electro-hydraulic  ^ear  and 

alsS^to  a  linear  positional  servo  attached  to  the  engine 
control  mechanism. 

Figure  9  shows  a  section  of  the  cross-track  error  as 
the  ship  is  guided  into  Plymouth.  Initially  the  vessel  is 
zSmSf  trick,  but  quickly  locks  on,  to  lie  generally 
within  5  m  of  the  desired  position. 
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DisPLACETENT  TRACK  ERROR  vb-ocitt 


Figure  9.  Cross-Track  Error;  Full-Scale  Sea  Trials. 

8 .  COMCLaSIOHS 

In  designing  a  ship  guidance  system,  the  overriding  aim 
is  to  improve  safety  at  sea.  As  increased  reliance  is 
placed  upon  automatic  systems  it  is  essential  that  they 
maintain  high  integrity  at  all  times.  It  is  also  important 
to  keep  the  ship's  master  informed  as  to  what  events  are 
taking  place  so  that  he  is  always  in  a  position  to  override 
the  automatic  system  in  the  case  of  failure,  or  when  he 
deems  it  necessary  to  do  so. 

The  developments  described  in  this  paper  form  part  of 
the  overall  general  trend  to  increase  automation  at  sea. 
There  is  a  move  to  implement  Vessel  Traffic  Systems  in  all 
major  ports.  Such  systems  will  rely  on  advanced 
surveillance  and  communication  techniques,  which  together 
with  shipborne  automatic  guidance  systems  will  increase 
efficiency  of  port  operation  and  at  the  same  time  improve 
safety  levels. 


3.399 


MOKEMCIATORB 


K  Discrete  state  transition  matrix. 

B  Discrete  control  matrix. 

C  Discrete  disturbance  matrix. 

F  Continuous  time  system  matrix. 

Continuous  time  forcing  matrices. 

Q  State  error  weighting  matrix. 

R  Control  weighting  matrix, 

r  Desired  state  vector. 

8  Feedback  gain  matrix, 

u  Control  vector. 

'‘opt  Optimal  control  vector, 

y  Noise  vector. 

H  Riccati  matrix, 

y  Disturbance  vector, 

jj  Ship  related  state  vector, 

y  Best  estimate  of  ship  related  state  vector. 


n^.hD 

5ii**'*J12  12 

r 

^11 '‘^12 '*'13 
T 

Tn.TR 

u,Uc,Ua 

V,Vc,Va 

x,y,z 

w 

X,Y,Z,M,N 

<A'^D 

S- 

e 


Ship  moment  of  Inertia  about  y  axis 
Ship  moment  of  inertia  about  z  axis. 

Integer  counter. 

Ship  mass. 

Actual  and  demanded  engine  speeds. 
Pitch-rate. 

Elements  of  state  error  weighting  matrix. 
Yaw  rate. 

Elements  of  control  weighting  matrix. 
Continuous  time. 

Sampling  time  interval. 

Time  constants  for  main  engines  and  rudder. 

Forward  velocity  of  ship,  current  and  air. 
Lateral  velocity  of  ship,  current  and  air. 
Ship  related  cartesian  coordinate  system. 
Z-direction  velocity. 

Hydrodynamic  coefficients. 

Actual  and  demanded  rudder  angles. 
Significant  wave  height. 

Heading  of  ship. 

Pitch  angle. 

Fin  angle. 
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